Fedora 45 发布流程与构建流水线

Fedora 45 通过一个高度自动化的流水线将源代码转换为可安装的制品，该流水线涉及源码控制、洁净室构建（clean-room builds）、门禁更新以及多阶段组合过程。该系统确保每一个 ISO、云镜像和容器镜像在交付给最终用户之前都是可复现、可审计且经过测试的。

源码控制与软件包定义

Fedora 在托管于 src.fedoraproject.org 的独立 Git 仓库中管理软件包定义（正在从 Pagure 迁移到 Forgejo）。每个仓库包含一个 RPM spec 文件、下游补丁以及一个指向 lookaside 缓存中上游 tarballs 的 sources 文件，以避免将二进制文件存入 Git。

打包者主要使用 fedpkg CLI 来管理这些仓库。当打包者运行 fedpkg build 时，该工具会生成一个指向特定 Git commit 的 URL 并将其提交给 Koji，从而确保构建可以从该 commit hash 完全复现。

构建系统：Koji

Koji 是 Fedora 的核心构建系统。它采用星型架构，由一个被动的 XML-RPC 服务器管理 PostgreSQL 数据库，构建守护进程（builder daemons）通过轮询该中心来获取任务。

为了确保可复现性，Koji 为每次构建都会创建一个全新的 Mock chroot 环境，防止来自先前构建的“泄漏”。系统使用 tags（构建的命名集合）来组织构建。构建目标（build targets）将请求映射到构建标签（定义构建根环境）和目标标签（完成后的 RPM 存放处）。Koji 还通过插件为 Kiwi 镜像、Image Builder 和 OSTree 组合编排非 RPM 制品。

更新门禁：Bodhi

对于分支版本，RPM 不会直接从 Koji 转移到用户手中。相反，它们受到 Bodhi（更新管理系统）的门禁控制。Bodhi 管理更新通过三个状态的转换：待定（pending）、测试（testing）和稳定（stable）。

更新根据“karma”（用户和自动化测试反馈）以及在测试阶段花费的时间向稳定性迈进。关键路径软件包——即对启动和基本功能至关重要的软件包——面临更严格的要求，包括更长的测试期（14 天而非 7 天）和更高的 karma 阈值。Bodhi 与 Greenwave 和 ResultsDB 集成以进行 CI 门禁，一旦更新被标记为稳定，Bodhi 会调用 Pungi 来组合实际的 DNF 仓库。

发布组合：Pungi

Pungi 是协调各种工具的编排器，将单个 RPM 转换为最终产品（如 ISO 和云镜像）。该过程遵循严格的顺序以保持一致性：

1. 软件包集冻结 (Pkgset)

Pungi 首先对特定的 Koji tag 进行快照。这个 Pkgset 阶段确保后续所有步骤都使用一组冻结的软件包，使整个组合过程可审计，并防止新的 Koji 构建混入正在进行的发布中。

2. 产品定义 (Comps and Variants)

Pungi 使用两个 XML 输入来确定产品组成：

• Comps (fedora-comps)： 定义软件包组（例如 gnome-desktop）以及每个软件包的角色（强制、默认、可选或条件）。
• Variants XML： 定义特定产品（例如 Workstation, Server, Silverblue）以及它们包含哪些 comps 组。

3. 引导镜像与 ISO 制作

• Buildinstall： 使用 lorax 创建 boot.iso，这是启动 Anaconda 安装程序的最小镜像。它是所有安装器 ISO 的基础。
• Createiso： 使用 xorriso 将软件包和仓库元数据叠加到 boot.iso 上，从而生成最终的 dvd.iso（主要用于 Server 版本）。

4. 专业镜像构建

Fedora 为非传统 ISO 提供三种主要路径：

• Kiwi： 构建云镜像（AWS, Azure, GCP）、Vagrant boxes、容器基础镜像和 WSL 镜像。它使用 XML 定义并通过 kiwiBuild 任务类型与 Koji 集成。
• Image Builder： 基于 osbuild，处理基于 OSTree 和 bootc 的制品，包括 Atomic Desktop ISO、Fedora IoT 和 Fedora Minimal。它使用沙箱阶段的流水线来处理 JSON 清单。
• rpm-ostree： 对于 Atomic Desktops（Silverblue, Kinoite 等），rpm-ostree compose tree 根据 YAML treefiles 创建一个版本化、带校验和的文件系统树（一个 OSTree commit）。comps-sync.py 脚本确保这些 treefiles 与标准的 comps XML 定义保持同步。

元数据与验证

每次组合都会通过 productmd 库生成标准化的元数据，产生诸如 composeinfo.json、images.json 和 rpms.json 等文件。这些文件对下游工具至关重要：Anaconda 使用它们来查找安装树，openQA 使用它们来定位用于测试的镜像。

使用 openQA 进行自动化测试

组合完成后，openQA 会在虚拟机中启动镜像以运行自动化场景，包括安装工作流、桌面功能和升级路径。每晚的 Rawhide 和里程碑组合（Beta, Final）总会触发 openQA 运行，在此发现的阻断性 bug 可能会停止发布。

治理：变更流程 (Changes Process)

对 Fedora 流水线或系统默认设置的重大修改通过 Changes 流程进行管理。提案分为 System-Wide（需要 FESCo 批准和详细的应急计划）或 Self-Contained（范围限于特定软件包）。所有变更必须在 Rawhide 中实现并满足特定截止日期（如 Beta Freeze），才能包含在发布中。

来自社区的技术见解

社区讨论强调了这种端到端可见度对于故障排除的重要性。一位贡献者指出，理解镜像制作流水线对于诊断版本之间发生变化的文件系统权限问题至关重要。然而，关于 Koji 的洁净室构建也提供了一些历史背景，一位用户指出，在过去，由于环境状态，未列在 Build-Requires 中的依赖项偶尔可能会泄漏到构建中，尽管这在现代迭代中已不常见。