Portal:Backports

欢迎来到 Backports 门户编辑

SUSE Linux Enterprise Server 和 Desktop 附带有限的软件包集合。这些软件包在向客户提供的 SUSE Linux Enterprise 技术支持服务下得到支持。另一方面，数千个额外的软件包由 openSUSE Build Service 中的志愿者维护，供 openSUSE 和其他发行版使用。许多软件包也为 SUSE Linux Enterprise 产品维护。

为 SUSE Linux Enterprise 维护的软件包存在于许多不同的独立项目中——特别是“devel”项目。这些软件包中的许多对 SUSE Linux Enterprise 客户来说很有用，但其中一些如果安装，可能会干扰 SUSE 产品的功能和可支持性。破坏可支持性的风险使得 SUSE 难以向最终客户推荐这些社区维护的软件包。与此同时，SUSE 鼓励社区努力，并希望向所有用户推广基于社区的软件包。

Backports 项目的想法是收集为 SUSE Linux Enterprise 构建的 openSUSE 软件包到一个中央仓库中。该仓库的策略与 SUSE 对齐，以维护主操作系统的可支持性，使软件包“安全”地安装和使用。

目前 Backports 项目的目标是 SUSE Linux Enterprise 12 GA (SLE-12)。如果需求量大，可能会考虑 SUSE Linux Enterprise Server 11 的目标。

特性编辑

对打包者有利

除了对用户有益之外，Backports 项目还可以帮助打包者。如前所述，SUSE Linux Enterprise 产品附带有限的软件包集合，并且通常不能满足构建额外软件包的所有要求。这通常会导致打包者“维护”所有额外的依赖项，而不仅仅是核心软件包集合。这导致在需要这些额外内容的各个不相连的项目中重复工作。有了 Backports 项目，软件包被整合到一个仓库中，而不是在每个需要它的项目中维护 libfoo，libfoo 由 Backports 项目作为通用的构建目标提供。Backports 项目中的软件包越多，每个人受益就越多。openSUSE:Backports 项目在某种程度上非常类似于 openSUSE:Factory 项目。事实上，它不仅类似于 Factory，而且是 Factory 的衍生品。

来自 Factory

在规划一个用于维护为 SUSE Linux Enterprise 发行版构建的社区软件包的通用项目时，很明显，需要制定一些策略和标准，以确保结果是我们都能支持和广泛推广的东西。为了避免重新发明和重复工作，决定简单地利用 openSUSE:Factory 项目的打包策略和质量检查。最简单的方法是仅接受通过 Factory 提交过程的软件包源代码。

如果软件包已经存在于 openSUSE:Factory 中，并且它能够针对 openSUSE:Backports:SLE-12 项目进行构建，那么它可以提交到 Backports 项目。从那时起，该软件包可以并行地在两个项目中维护。如果软件包不在 Factory 中，则需要先提交并接受它，然后才能被接受到 Backports 项目中。

有关更多信息，请参阅 Backports 打包策略。

回滚

openSUSE:Backports 项目被构建为“维护”项目。这是一种特殊类型的项目，它不仅包含软件包的最新构建版本，还包含以前版本的历史记录。这也是 openSUSE Updates 项目的管理方式。

通过提供以前的版本，如果更新导致问题，可以回滚到最后一个可用的版本。这使得项目在更新方面更加自由，同时为用户提供了一定的安全保障，以防出现问题。

持久性

通常在社区 OBS 项目中，某些目标发行版会随着时间的推移被放弃。SUSE Linux Enterprise 11 软件包正在发生这种情况。随着项目放弃 SLE-11 目标，转而支持 SLE-12 目标（也许是由于依赖关系），SLE-11 仓库以及对二进制文件的公共访问权限也会被删除。

使用 openSUSE:Backports 项目，软件包构建将维护在 SUSE Linux Enterprise 产品的整个生命周期中。事实上，每个软件包版本和更新都将始终可用，无论原始社区项目如何发展。

主题编辑

链接编辑

Portal:Backports

欢迎来到 Backports 门户 编辑

特性 编辑