LWN：Debian的秘诀！

关注了就能看到更多这么棒的文章哦～

Debian's "secret" sauce

By Jake Edge
October 14, 2024
DebConf
Gemini-1.5-flash translation
https://lwn.net/Articles/990177/

虽然 Debian 的“秘诀”(sauce) 并不是真正意义上的秘密，但它也不是特别知名。Samuel Henrique 在他于DebConf24 上的演讲开头说道。为了创建和维护 Debian 发行版，该发行版投入了大量软件工程方面的努力，但“许多人对此并不知情”。这可能是由于所有这些内容都没有真正记录在某个可以让他直接提供的中心位置。正是意识到这一点才促使他发表了这场演讲；希望它将成为“帮助解决这个问题的第一步”。

Henrique 表示他是一名巴西人，自 2018 年以来一直是 Debian 开发者。他主要在安全工具打包团队 工作，但也维护着该团队之外的一些软件包，包括 curl 和 rsync。此外，他还指导 Debian 新人，主要是在打包任务方面。他在亚马逊 Linux 安全团队工作。他指出，他的网站 包含指向演讲的幻灯片 的链接；一个WebM 视频 也已发布。[ 更新 ：一个带有英语和葡萄牙语字幕的YouTube 视频 也已发布。]

基础

发行版是一个旨在分发软件的项目；例如，它可以选择默认设置，或调整软件包的行为，从而使其更易于使用，这是该工作的一部分。但重要的是不要在这些软件包中发布错误或其他问题，包括安全问题。一些发行版试图尽可能地保持与上游代码的一致性，但“在 Debian 中，我们喜欢改进事物”，通过“运用我们自己的判断”来改进代码。

除此之外，该项目还需要支持它所发布的任何内容。这意味着需要制定流程，以“确保我们能够跟进报告出来的问题”并修复它们。该项目始终需要支持当前的 Debian 稳定版，并且同时开发下一个稳定版。“我们必须同时做这两件事，这是一个持续的过程。”

Debian 社会契约 以“意识形态的方式”使该项目保持一致；例如，它为“自由软件”提供了一个定义。Debian 章程 为该项目如何运作、如何分配权力、如何做出决策等提供了一个框架。在技术层面上，策略手册 描述了软件包应该如何（以及不应该如何）运作，以及如何将它们组合在一起。最后，开发者参考手册 旨在向打包人员提供关于如何遵循策略以及描述可以提供帮助的工具的建议。这些文档有助于创建一个“紧密组织，并且大家大体而言都在共享相同的目标，遵循相同的规则”，这为该项目所做的工作奠定了基础。

Debian 的形式

Henrique 表示，该项目与多个发行版和存储库合作。例如，想要尝试某事的 Debian 开发者可以将其推送到Debian experimental 存储库，该存储库通常只包含少量软件包。Experimental 不是一个完整的版本，因此需要在运行Debian unstable 的系统上启用它，然后才能安装来自 Experimental 的软件包。

Unstable 也称为“sid”，是一个完整的版本，因此可以安装在系统上。Unstable 是一个滚动发行版，它“不断更新”，并且没有官方支持，因此“你不应该在生产服务器上安装它”。Debian testing 也是一个滚动发行版，但它“比 Debian Unstable 更稳定”。

最后，还有Debian stable，“你应该在生产服务器上运行的版本”。还有oldstable，它是之前仍在受支持的稳定版。backports 存储库为“Debian 稳定版用户提供较新的软件包”；它旨在为用户提供灵活性，但作为发行版“没有官方支持”。

架构

Debian 支持 20 种架构，“其中 9 种是官方的，11 种是非官方的”。官方是指稳定版和 oldstable 中的所有软件包以及 unstable、testing 和 experimental 中的软件包都是针对这些架构构建的。非官方架构只为 stable unstable、testing 和 experimental 构建软件包。架构列表“不断变化”；Debian 的发布团队 在每个新的稳定版发布之前都会确定哪些架构是官方的，哪些是非官方的。他表示，这个决定通常归结为对架构的长期支持问题：是否有足够的构建软件包的基础设施和足够的人手来帮助支持它们？

Henrique 展示了一个来自buildd.debian.org 网站 的屏幕截图，该截图显示了所有架构上 sid 上的coreutils 软件包的构建状态。绿色表示构建成功，红色表示构建失败（当前只有 hurd-i386，在他的屏幕截图中）。该页面显示了构建失败的日志；也可以在该站点上查看先前构建和其他发行版的結果。

他表示，支持多种架构很重要，因为它可以发现错误。目前，Debian 支持两种非 Linux 内核的架构，两者都是针对GNU Hurd 在 x86 系统上构建的，尽管它曾经也支持kFreeBSD。它支持大端和小端系统，以及 32 位和 64 位架构；C 数据类型的大小也存在多样性。所有这些都在 Debian wiki 上进行了总结。这种多样性使更容易在上游软件中发现问题，即使比如开发人员没有办法获得一个大端系统来测试的情况。“因此，如果你的软件针对 Debian 打包，你至少会知道它是否可以运行”；维护人员可能关心这一点，也可能不关心，但他们至少会知道。

Henrique 指出了一份针对GoAWK（一个用 Go 编写的 AWK 实现）的测试修复，该修复是在 32 位系统上构建时完成的。它针对 Debian 打包并作为 unstable 版本的一部分进入发行版，当时发现了问题；Debian 维护者向其上游报告 并开发了一个修复方案。Debian 显然是第一个在 32 位系统上构建和测试 GoAWK 的。

另一个例子是他报告 的Aircrack-ng WiFi 安全工具中的一个错误。事实证明，这是一个在大端系统上构建和运行测试的问题。他表示，这种情况以前也发生过，并且很容易发现，因为所有五个大端架构突然开始报告构建/测试问题。

存储库

Henrique 创建了以下图表，以帮助与会者了解软件包如何流入开发存储库：experimental、unstable 和 testing。左上角的 Debian 开发者有四个不同的位置可以发送新软件包或更新的软件包。他们可以直接将软件包放入 experimental 或 unstable 存储库，或者将要发布到 testing 的更新发送到发布团队（用于定期更新）或安全团队（用于安全修复）。

他指出，experimental 存储库在图表中没有进一步连接，“它什么地方也不去”，这符合它的使用方式。该存储库使“测试事物变得非常容易”。例如，如果他想要为某个软件包启用一个新的架构并使其可供其他人测试，他可以将其上传到 experimental；这也会导致一些自动测试的进行，从而生成有用的报告。“我提前看到了如果我将这个软件包发送到 unstable 会发生什么。”

在 experimental 中撤消更改很容易，因为可以简单地删除该软件包。此外，成功的更改可以推送到 unstable，这允许同时使用同一个软件包的两个变体。curl 打包人员最近在将 TLS 后端从 OpenSSL 更改为 GnuTLS 时使用了这种能力；GnuTLS 版本在 experimental 上停留了一个月左右，而 OpenSSL 版本在 unstable 上更新了几次。

unstable 存储库没有提供受支持的发行版，但它确实提供了所有可用的软件包，这与 experimental 不同。然而，它“由专家用户安装和使用”；由于它是新软件包出现的第一站，许多开发人员都会使用它。unstable 中的软件包会从测试和 QA 基础设施中获得全面的覆盖。由于它可能会破坏其他软件包，因此“重要的是不要严重破坏事物”；对于有风险的更改，应该使用 experimental 而不是 unstable。

unstable 中的软件包在“遵循一些规则后”会自动迁移到 testing；该软件包需要通过测试并在 unstable 中停留一段时间才能被提升。虽然 testing 也不受支持，但它通常比 unstable 稳定得多，因为那里的软件包将要发布到下一个 Debian 稳定版。最近在64 位 time_t 转变 方面出现了一些问题，影响了 testing，但“这种事情可能每 20 年发生一次”；这表明 testing 仍然可能出现故障，但总体上“相当稳定”。

与 experimental 或 unstable 不同，testing 提供了一个安装程序，以便安装团队可以在发布之前对其进行测试。这意味着可以从头开始安装 testing。他建议将 testing 用于非服务器用例，例如桌面。“我认为它与任何其他滚动发行版一样稳定”，这得益于发行版所制定的所有检查和流程。

稳定版

Henrique 表示，在考虑 Debian 稳定版时，需要考虑两个方面：创建和维护。创建每两年进行一次，方法是使用 testing 的快照；创建之后，软件包不会像 unstable 或 testing 那样更新。运行稳定版的用户追求的是可预测性，而不是没有错误的东西；“关键是每天不会出现十个新的错误”。

但需要有一个时间，在此期间，软件包不能自由地从 unstable 迁移到 testing，以便稳定将要成为稳定版的内容。发布团队有一个冻结过程，它会改变软件包迁移到 testing 的能力。软件包迁移的要求会随着冻结过程的不同阶段而变化，并变得越来越严格；在最后阶段，任何更改都需要由发布团队手动审查和批准。

用于Debian 12（“bookworm”） 发行版的最后一次冻结持续了大约六个月。在冻结期间，unstable 和 testing 存储库中的活动会减少，因为重点是修复 testing 中的内容；但要发布到 testing 的更新仍在推送到 unstable。

然而，在冻结期间推送到 unstable 的一些软件包可能不会发布到稳定版；如果需要修复 testing 中该软件包的版本，则必须采取不同的路径。这就是 testing-proposed-updates 和 testing-security 存储库（来自图表）发挥作用的地方；经过发布团队或安全团队的手动审查，补丁可以进入这些存储库，然后从那里进入 testing。

不过，一旦发布了稳定版，软件包更新的路径也需要由其中一个团队根据“修复的性质”手动审查。关键的安全修复，例如针对 CVE 的修复，可以直接进入稳定版，但其他修复将“在 proposed-updates 中停留一段时间”；通常的要求是软件包在移至稳定版之前需要在 proposed-updates 中停留一周。发布团队会定期暂停从 proposed-updates 迁移到稳定版，以便创建一个点版本。

工具

Debian 中有“无数工具”可用于执行各种测试，例如持续集成 (CI) 或一般 QA。他在演讲中选择重点介绍其中的几个，但所有这些工具都是免费提供的；“任何人都可以查询 Debian 软件包的所有构建日志，识别错误模式，并提供补丁”来修复发现的问题。对于那些好奇的人，Debian QA 小组维基页面 涵盖了完整的工具集以及该小组使用的流程。

dh_auto_test 工具 与软件包构建系统挂钩，并在构建软件包后尝试运行上游测试。它可以检测到像 makefile 中的测试目标，并自动运行它们，但如果它无法确定如何运行测试，则可以将其配置为运行任何感兴趣的测试。它旨在确认该软件包在 Debian 环境中、针对其所有架构以及使用发行版使用的构建标志（包括加固选项）可以正常工作。即使上游项目也在运行其测试，但 Debian 使用的依赖项可能不同；“有时我们会在所有这些差异中发现问题”。

Lintian 对软件包进行许多不同的测试，以查找“愚蠢的事情，例如拼写错误”或更严重的问题，例如是否存在没有源文件的二进制文件。它与构建过程挂钩，如果它检测到足够严重的问题，该软件包将被拒绝。他对 curl 软件包的第一个贡献是针对 Lintian 检测到的一个问题：在发行版切换到 Python 3 之后，curl 在测试中仍然使用 Python 2，这很容易修复。

Autopkgtest 标准化了软件包的测试定义，以便它们可以作为 CI 系统的一部分运行。这些测试不是构建时测试，而是用于运行打包软件的端到端测试。autopkgtest 脚本通常包括运行上游测试，但通常会添加额外的测试；“你在这里有很大的自由度”来添加测试软件的各种方式所需的依赖项。

虽然 autopkgtest 是使用的机制，但debci 是持续运行测试的服务，其结果可以在ci.debian.net 上看到。它会针对每次更改“在很长一段架构列表上”运行这些测试，但并非所有发行版支持的架构。它产生的主要成果是测试报告，这些报告可用于确定软件包是否应该从 unstable 迁移到 testing。

某个软件包将被测试，但这不仅仅是测试它；它的依赖项也会被测试，同样被测试的还有依赖它的软件包或进行测试的软件包。目的是查找回归，即软件包的先前版本通过测试，但现在不再通过；因此，当测试失败时，会测试先前版本，以查看它是否也失败。因此，如果软件包 A 被上传到 unstable，debci 会查看哪些软件包依赖它，例如找到软件包 B；然后，它会使用 A 的旧版本和新版本运行 B 的测试，并比较结果。所有这些都可以在tracker.debian.org 上按软件包查看，例如glibc 软件包。

他给出了两个例子，说明了这个过程如何找到可能在其他情况下没有被注意到的错误。针对 aeskeyfind 实用程序的2021 年测试失败，aeskeyfind 是一个在内存中查找 AES 密钥的法证工具，它默默地失败了，因为它依赖于由于不同 GCC 版本而发生变化的未定义行为。由于 aeskeyfind 没有维护，其他发行版也可能存在这个问题，尽管 Henrique 试图让大家知道。

另一个是UDPTunnel 测试的失败，这是由于Nmap 端口扫描程序的更改造成的。问题是 Nmap 中的一个隐藏的回归，它被 autopkgtest 和 debci 检测到，这导致了Nmap 错误报告 和随后的修复。

Salsa CI 是他最喜欢的工具之一；它基于 Debian GitLab 实例出来的 Salsa，有助于“确保我们的软件包都很好很稳定”。Salsa CI 团队 为软件包的单个提交上运行的测试提供食谱（recipe）。他展示了curl 的 Salsa CI 页面，该页面列出了运行的许多不同测试，包括构建测试、autopkgtest、针对可能缺少构建标志的测试（例如，用于加固）、构建可重复性测试等等。他还简要地提到了其他一些工具，包括一个用于确保不存在多架构问题 的工具和Janitor，它会主动扫描源代码库，并发送带有建议改进的合并请求。

一位听众询问了其他发行版在 QA 方面做了哪些事情。Henrique 表示他知道一些其他发行版，包括 Fedora，它也有一些等效的系统和流程，但他认为 Debian 是“今天做得最好的”。随着时间的推移，会议结束了。总的来说，他在演讲中对 Debian 的开发和维护进行了很好的概览，并且帮助展示了秘诀的配方。

[我要感谢 Linux 基金会，LWN 的旅行赞助商，感谢它帮助我前往釜山参加 DebConf24。]

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～