SDB:Backports
自由软件开发中的“流”隐喻
在理解自由软件开发时，“流”的隐喻非常有用。自由软件被编写，并通过像 openSUSE 这样的项目与其他软件集成，以构建一个分发版，然后被最终用户使用。因此，软件从其开发者向下游流动，经过集成者，最终到达最终用户。
反馈通常以相反的方向流动：用户向其分发版供应商报告错误或要求功能增强，而供应商又与上游开发者合作以修复错误或开发增强功能。
自由软件开发中的角色
通过“流”隐喻，我们可以看到在自由软件开发中存在各种可识别的角色：上游开发者、分发版开发者和最终用户。这些角色具有不同的兴趣、目标或责任。
上游开发者的主要兴趣在于软件本身的开发；与其他软件的集成不太重要。在大多数情况下，上游开发者因此只积极地处理其项目的“分支”之一或两个。
然而，对于分发版开发者来说，这才是主要关注点：将各个软件部分组合成一个连贯、集成的整体。为了帮助实现这一目标，分发版开发者通常充当上游开发者和最终用户之间的沟通过滤器，帮助分析最终用户的问题，并将分析结果传达给上游开发者，并在可能的情况下帮助他们开发和测试补丁以解决这些问题。分发版开发者通常在其产品的多个版本或基于较旧软件版本的相关但不同的多个产品上提供支持。
最后，最终用户的首要关注点是使用软件进行高效工作。
但最终用户关注的重点不同。有些人非常热衷于跟踪“最新和最棒”的软件，而对于其他人来说，提供长期支持的稳定环境更为重要。Novell 的 Linux 产品在某种程度上反映了这些不同的兴趣：对于某些产品，新版本发布得相当频繁，但每个版本仅支持相对较短的时间，而其他面向企业的产品发布得较少，但支持时间更长。
Backports
由于上游开发者主要关注于他们开发的软件的进步，在许多情况下，他们将修复错误与引入尚未经过广泛测试并且可能引入新错误的特性结合起来。
对于分发版开发者来说，重要的是区分具有有限破坏功能的可能性错误的修复和可能破坏现有功能的更改。在大多数情况下，分发版开发者不会跟踪所有上游更改一旦软件包成为已发布分发版的一部分，而是坚持他们最初发布的上游版本，并基于上游更改创建补丁以修复错误。这种做法被称为回溯移植，因为软件较新版本中的更改被调整并应用于较旧版本。
分发版开发者通常只会在两种情况下引入较新的软件版本：当他们的软件包与上游版本的更改变得非常大以至于回溯移植不再可行时，或者对于本质上会迅速过时的软件，例如反恶意软件（因为恶意软件编写者和反恶意软件编写者正在进行进化军备竞赛）。
回溯移植的原因
openSUSE 广泛使用回溯移植，因为它们在软件的许多关注点之间取得了良好的平衡。其中最重要的包括
- 拥有软件供应商可以依赖的稳定接口（API），以便在 openSUSE 上构建产品。
- 确保 openSUSE 版本的软件包质量最高，并且已经过彻底测试，无论是在自身还是作为整个分发版的一部分。
- 维护其他供应商对 openSUSE 的各种认证。
- 允许 openSUSE 的开发者专注于使产品的下一个版本尽可能地好，而不是让他们将注意力分散到广泛的发布版本上
- 清晰地了解特定 openSUSE 版本中包含的内容，以便社区可以为其提供准确及时的技术支持。
不使用回溯移植的原因
一般策略规则是，不将新的上游软件包版本引入到 openSUSE 版本中。然而，这条规则并非绝对规则。对于有限的软件包类别，安全问题比质量保证角度的首选保守方法更重要。对于该类别的软件包，有时会引入较新的版本到已发布版本的 openSUSE 中。
有时，对于其他类型的软件包，也会选择引入新版本而不是回溯移植。这是在制作回溯移植不可行或存在非常相关的技术原因来引入较新版本时完成的。
回溯移植对解释版本号的影响
由于回溯移植的做法，不能简单地比较版本号来确定 openSUSE 软件包是否包含特定问题的修复程序或是否已添加了特定功能。通过回溯移植，openSUSE 软件包的版本号的上游部分仅仅指示软件包基于哪个上游版本。它可能包含上游相应版本中没有的错误修复和功能，但已回溯移植到 openSUSE 软件包中。
有几个位置存储了有关此类错误修复和功能的信息
- 软件包的变更日志rpm -q --changelog 已安装软件包名称或rpm -qp --changelog 软件包文件.rpm此变更日志简要记录了软件包的更改历史记录。
- 软件包变更日志可能包含类似于“bnc#1234”的条目，这些条目引用了错误
- 在 openSUSE 的 bugzilla 错误跟踪系统中或链接到其他错误跟踪系统。（由于保密政策，并非所有此类信息都可供您访问）
- 软件包可能包含一个/usr/share/doc/软件包名称/README.SUSE或README.SuSE文件，其中包含特定于 openSUSE/SUSE 封装的一般、高级别信息。
- RPM 源代码软件包包含在构建常规二进制 RPM 时应用的补丁作为单独的文件，如果您熟悉阅读源代码，可以解释这些文件。请参阅 Maximum RPM book 以获取更多信息。
- 对于安全漏洞修复，openSUSE 安全公告 和 CVE Index。这些通常通过标准名称（如“CAN-2005-2495”）引用漏洞，这些名称由 Common Vulnerabilities and Exposures 项目维护。
一个特别容易出现问题的地方是，当涉及回溯移植时，版本号的价值有限，这会影响安全扫描工具。一些安全漏洞扫描工具（或此类工具中的特定测试）仅基于版本信息运行。因此，这些工具/测试容易在涉及回溯移植时生成“误报”（声称已找到易受攻击的软件，但实际上并非易受攻击）。在评估安全扫描工具的报告时，应始终调查条目是仅基于版本号还是基于实际测试是否存在实际漏洞。