更高效的 Factory 开发

openSUSE Factory 发行版是我们的永久开发发行版。目前用于开发 openSUSE 11.2。我们希望使 Factory 发行版对每个人都更易于使用，以便更好地测试下一个版本。近年来我们收到的一项抱怨是，大量新构建的软件包使得人们很难保持系统更新，仅仅是因为下载和安装软件包所需的时间。

我们现在已经切换到一种新的机制，这将显著减少发布的软件包数量。为了解释这种新机制，我们应该回顾一下构建发行版的旧概念

1) 手动触发构建 这个概念自 Linux 发行版诞生以来一直使用，并且至今仍被多个发行版使用。它只是意味着一个软件包只有在有人明确指示时才会编译。

这具有以下优点：

• 仅构建所需的最小数量的软件包。这对于编译资源和带宽而言是好的。
• 意外的不兼容性会变得为人所知，因为问题会显而易见地暴露出来。

缺点是：

• 需要进行大量的审查工作才能了解哪些软件包可能受到更改的影响并触发其构建。
• 和/或发行版树会经常损坏且无法使用，因为存在不兼容性。
• 即使这些更改可能不是问题的根源，新的问题也会显现出来。
• 因此，此发行版的维护更新将受到影响，因为可能需要进行更大的更改，而不仅仅是小的错误修复。

2) 完全自动化的构建触发

到目前为止，SUSE 的方法是，只要一个软件包发生更改，所有其他依赖软件包也会被重新构建。构建结果始终是一个干净的发行版，可以以相同的方式被每个人重建。

这种方法的优点：

• 新问题会立即显现出来
• 只要软件包仍然可以编译，不兼容性就会自动解决
• 保证干净的构建结果，可以通过构建时间来验证（无法构建的软件包是一个例外，但这些很容易看到）。

这种方法的缺点：

• 不兼容性可能不会被发现。
• 大量的软件包，即使它们没有更改其内容。
• 需要大量的构建能力。

显然，这两种概念都有其优点和缺点。由于我们仍然希望交付一个可维护的发行版，我们认为我们不能放弃概念 2)。但我们认为可以减少其缺点

从现在开始，构建结果可以与以前的构建结果进行比较。openSUSE 构建服务只会放弃构建结果，如果新的构建本质上相同，并基于旧的构建结果计算构建依赖关系。这将减少要构建的软件包数量，但也会更进一步地减少实际发布的软件包数量。因此，我们认为这是一种结合两种构建策略优势的解决方案。

比较是通过分发中的脚本完成的。您可以在 openSUSE:Factory 中的 build-compare 软件包中找到这些脚本。这些脚本由 Michael Matz 和 Coolo 开发，当然仍然可以改进。

现在我们希望保持保守的态度，并发布新的构建以防万一。但是，我们可能会更改一些工具以避免将时间戳写入文件，例如。或者我们将增强脚本以忽略更多更改。

此脚本现在对 openSUSE:Factory 中的所有构建或在您的项目中为它构建软件包时都处于活动状态。它尚未对针对其他发行版的构建处于活动状态，但是我们可能会在经过更多测试后为它们启用它。