6 向后移植源代码 #
SUSE 广泛使用了向后移植，例如当前的软件修复和功能迁移到过去发布的 SUSE Linux Enterprise 包中。本章中的信息解释通过比较版本号来判断 SUSE Linux Enterprise 软件包的功能和安全性为何有误导性。此外，本章还会说明 SUSE 如何在确保系统软件安全且最新的同时，保持 SUSE Linux Enterprise 产品上所运行应用程序软件的兼容性。您还将了解如何检查在 SUSE Linux Enterprise 系统软件中实际解决了哪些公共安全问题，以及您的软件的当前状态。
6.1 向后移植的原因 #
上游开发者主要关心所开发软件的进度。他们往往会在修复 bug 的同时引入尚未经过广泛测试并可能会造成新 bug 的新功能。
对于分发包开发者而言，必须区分两种情况：
在对功能造成有限中断的情况下执行的 bug 修复；以及
可能会中断现有功能的更改。
通常情况下，当某个包已属于所发布的发行套件时，发行套件开发者不会遵照所有的上游更改。通常，他们会继续使用最初发布的上游版本，并根据上游更改来创建增补程序以修复 bug。这种做法称为向后移植。
通常，分发包开发者只会在两种情况下引入软件的更新版本：
当他们的包与上游版本之间的差异过大，以致向后移植的做法不再可行，或者
软件（例如防恶意软件的软件）由于固有的性质而变得不合时宜。
由于我们致力于在几个企业软件考虑因素之间实现合理的平衡，SUSE 广泛使用了向后移植。其中，最重要的考虑因素包括：
提供稳定的接口 (API)，软件供应商在构建可用于 SUSE 企业产品的产品时可以依赖这些接口。
确保 SUSE 企业产品版本中使用的包具有最好的质量，这些包本身以及在成为整个企业产品的一部分后已经过充分的测试。
由其他供应商对 SUSE 的企业产品维持各种认证，就像对 Oracle 或 SAP 产品的认证一样。
让 SUSE 开发人员专注于开发下一个产品版本，而不是顾此失彼地将精力分散在众多不同的修订版上。
清楚明了特定企业版本中包含的功能和特性，以便我们的支持可以提供有关该版本的准确及时的信息。
6.2 反对向后移植的原因 #
不要将新的上游包版本引入我们的企业产品，这是常见的策略规则，但不是硬性规则。对于特定的包类型，尤其是防病毒软件，安全方面是我们考虑更多的因素，而不是优先考虑质量保证方面的保守做法。对于这个种类的包，偶尔会将更新的版本引入企业产品系列的发布版本。
有时，对于其他类型的包，我们也会选择引入新版本，而不是向后移植。当生成向后移植在经济效益上不可行，或者由于极其相关的技术原因而需要引入更新版本时，我们会采取这种做法。
6.3 使用向后移植时解释版本号所产生的效果 #
由于采用向后移植的做法，用户不能简单地通过比较版本号来确定 SUSE 包是否包含针对特定问题的修复，或者其中是否添加了特定的功能。在使用向后移植时，SUSE 包版本号的上游部分只是表示 SUSE 包基于的上游版本。它可能包含相应上游版本中没有但已向后移植到 SUSE 包中的 bug 修复和功能。
在涉及到向后移植时，版本号的这种有限价值可能会造成在特定情况下产生问题，也就是在使用安全扫描工具的时候。某些安全漏洞扫描工具（或者在此类工具中进行特定的测试）只能基于版本号运行。因此，在涉及到向后移植时，这些工具和测试很容易生成“误报”（将某个软件错误地识别为有漏洞）。在评估安全扫描工具生成的报告时，请始终检查其中的条目是基于版本号，还是基于实际的漏洞测试。
6.4 检查已修复的 Bug 和向后移植的功能 #
有关向后移植的 bug 修复和功能等的信息储存在几个位置：
包的更改日志：
tux >rpm -q --changelog name-of-installed-packagetux >rpm -qp --changelog packagefile.rpm其输出简要记录了包的更改历史记录。
包的更改日志可能包含类似于引用 SUSE Bugzilla 跟踪系统中的
bsc#1234(“Bugzilla Suse.Com”) 之类的项，或者包含指向其他 Bug 跟踪系统的链接。出于保密政策的缘故，您不一定能够访问所有此类信息。包中可能包含
/usr/share/doc/PACKAGENAME/README.SUSE文件，该文件包含特定于 SUSE 包的一般概要信息。RPM 源包包含构建普通二进制 RPM 期间应用的增补程序，这些增补程序以独立文件的形式存在，如果您熟知如何阅读源代码，可以对这些文件进行解释。请参见第 6.1.3.5 节 “安装或下载源包”，了解如何安装 SUSE Linux Enterprise 软件的源。请参见第 6.2.5 节 “安装和编译源包”，了解如何在 SUSE Linux Enterprise 上构建包。请参见《Maximum RPM》（充分利用 RPM）一书，了解有关 SUSE Linux Enterprise 软件包构建的细节。
有关安全 Bug 修复，请查阅 SUSE 安全声明。这些声明往往通过公共漏洞和披露 (CVE) 项目所维护的标准化名称（例如
CAN-2005-2495）来称呼 Bug。