这是一个关于 Fedora 如何将源代码和软件包转化为您下载和安装的工件的指南。它跟踪一个软件包从打包者的 git 推送到组成的发布：ISO、云镜像、容器镜像和 OSTree 部署。这个指南描述了截至 Fedora 45 的 Fedora ‘香肠’ 是如何制作的；事情总是在变化；我希望能有时间在每个周期或每几个 Fedora 发布周期更新这个文档，以便有历史记录和人们能够找到最新的信息。实际上，这个文档目前仍在更新中，因为 Fedora 45 还没有发布，所以这个帖子可能会在发布之前不断更新。有几个变更提案正在进行中，改变这里的一些细节。特别是 boot.iso 的生成，这也是这个帖子相当大的一部分。因此，现在也是告诉我是否有任何错误的好时机，如果您发现任何错误，请通过电子邮件与我联系，地址是 cmdr@supakeen.com。起始行：dist-git 一切从打包者将提交推送到软件包开始。Fedora 将每个软件包的源定义存储在位于 src.fedoraproject.org 的单独 Git 存储库中。每个存储库包含一个 RPM 规范文件、任何下游补丁，以及一个指向存储在单独附加缓存中的上游 tarball 的源文件。大型二进制文件不在 Git 中，而其他文件存在于 Git 内部，因此具有完整的版本控制。打包者通常通过 fedpkg 与这些存储库进行交互，这是一个包装常见操作的 CLI：克隆存储库、上传源 tarball、提交构建和创建更新。fedpkg build 的重要之处在于它实际做的事情：它构造一个指向 Git 存储库中特定提交的 URL，并将其交给构建系统 Koji。构建可以完全根据该提交哈希可重复。分支映射到发行版：rawhide 用于开发，f44 用于 Fedora 44。托管分为 Pagure (src.fedoraproject.org) 和 Forgejo (forge.fedoraproject.org)，并且正在进行从前者到后者的迁移。打包者可以不使用 fedpkg 进行工作，但出于本帖的目的，假设使用 fedpkg 更容易，因为它抽象了一些与读者无关的细节。构建软件包：Koji 当 fedpkg build 提交该 Git URL 时，Koji 接管。Koji 是 Fedora 的构建系统。自 Fedora 7 以来它就存在，并几乎构建所有东西。Koji 遵循 hub-and-spoke 架构。中心是一个被动的 XML-RPC 服务器，位于 PostgreSQL 数据库前面。构建程序守护进程轮询中心以获取工作，为每个构建创建一个新的 Mock chroot 环境，运行构建并上传结果。每个构建都从干净的环境开始。您永远不会因为上周有人在构建机上安装过某些东西而得到不同的结果。组织模型围绕标签建立。标签是已命名的构建集合。构建目标将传入的构建请求映射到两个标签：构建标签（定义构建根，构建期间可用的软件包）和目标标签（完成的构建所在位置）。标签支持多重继承，因此您可以在基础标签之上叠加 Fedora 44 标签，而无需重复所有内容。Koji 不仅构建 RPM。通过其插件系统和内容生成器，它还协调镜像构建：通过 kiwiBuild 任务类型的 Kiwi 镜像、通过 imageBuilderBuild 的镜像构件以及通过 runroot 任务的 OSTree 组合。我们将讨论这些。更新门控：Bodhi 在 Koji 中的一个新 RPM 构建不会自动到达用户。对于分支发布（任何不是 Rawhide 的版本），它通过 Fedora 的更新管理系统 Bodhi 进行处理。Bodhi 通过反馈和测试周期对更新的发布进行门控。打包者提交包含一个或多个构建的更新。该更新经历一系列状态：待处理、测试、稳定。用户和自动化测试提供 karma (+1 / -1)。当更新的 karma 达到 +3 或在测试中花费了足够的天数，它将被自动推送到稳定版本。如果更新达到 +1 karma 维护者可以手动推送到稳定版本 (+2 用于关键路径)。在幕后，Bodhi 通过 Koji 标签管理所有这些。当更新从测试移动到稳定时，Bodhi 将构建从 f44-updates-testing 标签移动到 f44-updates 标签。然后它调用 Pungi 来组合更新库，即用户在运行 dnf upgrade 时从中提取的实际 yum/dnf 仓库。关键路径软件包，即您的系统需要启动和正常运行的软件包，要求更严格：在测试中需要 14 天而不是 7 天，并且需要更多的 karma。Bodhi 还与 Greenwave 和 ResultsDB 集成以进行 CI 测试门控，因此自动化测试失败可能会阻止更新到达稳定版本。对于 Rawhide，这些过程的配置有所不同。非关键路径软件包立即稳定，除非有门控策略（因为软件包在关键路径中或者软件包本身...）