Fedora 45 的“腊肠工厂”：产物构建流程详解
Hacker News 摘要原标题：The Fedora 45 Sausage Factory
这篇文章详细介绍了 Fedora 如何将源代码和软件包转化为用户可以下载并安装的各种产物。它涵盖了从打包者提交代码到生成最终镜像（如 ISO、云镜像、容器镜像和 OSTree 部署）的完整流程。该流程描述的是 Fedora 45 时的状况，因为 Fedora 的构建系统一直在不断演进。
起点：dist-git
一切始于打包者向软件包仓库提交代码。Fedora 将每个软件包的源代码定义存储在位于 src.fedoraproject.org 的独立 Git 仓库中。每个仓库包含一个 RPM spec 文件、补丁以及一个 sources 文件。sources 文件指向存储在外部缓存中的上游源码包。
打包者通常使用命令行工具 fedpkg 进行交互。当运行 fedpkg build 时，该工具会生成一个指向 Git 仓库中特定提交的网址，并将其发送给 Koji 构建系统。由于是基于特定的提交哈希进行构建，整个过程具有可重现性。
构建软件包：Koji
Koji 是 Fedora 的核心构建系统。它采用中心辐射型架构：中心服务器处理请求并管理数据库，而多个构建守护进程则负责实际的构建任务。
每个构建任务都在一个干净的 Mock 隔离环境中运行，确保构建结果不受之前任务的影响。Koji 的组织模型基于标签。标签可以定义构建时可用的软件包环境，以及构建完成后产物的存放位置。除了 RPM 包，Koji 还能通过插件系统调度镜像构建任务。
审核更新：Bodhi
对于非开发版本（如 Fedora 44 等正式分支），新构建的 RPM 包不会直接进入正式仓库，而是要经过 Bodhi 更新管理系统。
打包者提交更新后，该更新会经历待定、测试、稳定等阶段。用户和自动化测试会提供反馈（称为 karma）。当反馈达到一定标准或在测试阶段停留足够天数后，Bodhi 会将该软件包移动到稳定版标签，并调用 Pungi 来更新用户最终使用的软件仓库。关键软件包（如引导程序等）会有更严格的测试要求。
编排发布：Pungi
Pungi 是发布的编排者，负责协调各种工具以确保所有产物都基于同一组一致的软件包构建。它的工作分为几个阶段：
1. 冻结软件包集：Pungi 会在开始时快照 Koji 中的标签状态。这确保了在整个发布构建过程中，软件包版本不会发生变化。
2. 分组与变体：通过 comps 文件定义软件包组（如 GNOME 桌面、服务器工具等），并结合 variants.xml 定义不同的产品（如 Workstation、Server、Silverblue 等）。
3. 构建引导镜像：Buildinstall 阶段运行 lorax 工具来创建 boot.iso。这是安装程序的引导基础。
4. 生成 ISO：Createiso 阶段将软件包和元数据叠加到引导镜像上，生成最终的 DVD 安装镜像。
镜像构建工具：Kiwi 与 Image Builder
Fedora 使用多种工具来满足不同的镜像需求：
• Kiwi：主要用于构建云镜像、虚拟机镜像、容器基础镜像以及大多数桌面的 Live ISO。它通过 XML 文件定义镜像内容，并在 Koji 的隔离环境中运行。
• Image Builder：处理基于 OSTree 的系统镜像，如 Fedora IoT 和原子桌面（Atomic Desktops）。它底层依赖 osbuild，使用 JSON 格式定义构建流水线，且在高度沙盒化的环境中运行以确保安全。
原子桌面：rpm-ostree
Fedora Silverblue 和 Kinoite 等原子桌面与传统的软件包系统不同。它们不向用户发送一堆 RPM 包，而是发送一个经过版本控制和校验的文件系统树（即 OSTree 提交）。
构建系统使用 rpm-ostree 工具，根据 YAML 格式的定义文件，将一组 RPM 包转化为文件系统树。为了保持同步，系统会运行脚本从 comps 定义中提取软件包列表，确保原子桌面包含的软件与传统版本一致。
发布元数据：productmd
每个发布周期都会产生一组描述其内容的元数据文件，这些文件由 productmd 库生成：
• composeinfo.json：包含发布身份和变体定义。
• images.json：列出所有镜像的类型、格式、校验和与大小。
• rpms.json：列出按变体和架构组织的每个 RPM 包。
• .treeinfo：安装程序用来寻找安装源的关键文件。
这些文件被后续的各种工具（如镜像分发系统、测试系统）广泛使用。
自动化测试：openQA
当发布构建完成后，openQA 会自动接手进行测试。它会在虚拟机中启动生成的镜像，模拟用户的各种操作流程，如安装、桌面功能测试和系统升级。
测试脚本通过视觉匹配和代码逻辑来验证系统表现。如果是开发版本或里程碑版本（如 Beta 版），测试结果会直接影响发布决定。如果在测试中发现严重错误，发布可能会被推迟。
治理：变更流程
Fedora 的重大修改（如引入新工具、更改默认设置等）必须通过变更流程。
• 系统级变更：影响核心包或系统默认值的提议需要详细的计划和测试方案，并需经过 Fedora 工程指导委员会（FESCo）的审批。
• 自包含变更：仅影响特定软件包的提议审核相对较轻。
所有变更都有明确的最后期限。如果未能按时完成，变更将被自动推迟到下一个发布周期。
原文：https://supakeen.com/weblog/the-fedora-45-sausage-factory/