本文详细介绍了Fedora 45如何将源代码和软件包转化为可下载安装的制品，包括ISO镜像、云镜像、容器镜像和OSTree部署，并说明了整个流程从打包者提交代码到最终发布版本的过程。

好的，这是根据您的要求，对原文主要内容进行的中文重述，保留了关键细节，并删减了与主题无关的评论性内容。

Fedora 45 发布流程详解：从源码到成品

本文详细介绍了 Fedora 45 如何将源代码和软件包转化为用户最终下载和安装的 ISO、云镜像、容器镜像和 OSTree 部署等制品。

起点：dist-git

流程始于软件包维护者（packager）向软件包仓库提交代码。Fedora 将每个软件包的源码定义存储在独立的 Git 仓库中，包含 RPM spec 文件、下游补丁以及指向上游源码包的 sources 文件。维护者通常通过 fedpkg 命令行工具与这些仓库交互，执行克隆、提交构建等操作。fedpkg build 会构造一个指向 Git 仓库特定提交的 URL，并将其提交给构建系统 Koji。仓库分支与 Fedora 版本对应，例如 rawhide 用于开发版，f44 用于 Fedora 44。

构建软件包：Koji

Koji 是 Fedora 的构建系统，采用中心辐射型架构。中心节点是一个 XML-RPC 服务器，构建守护进程（builder）从中获取任务，为每次构建创建一个全新的 Mock chroot 环境，执行构建并上传结果。Koji 的组织模型基于“标签”（tag）。一个标签是构建产物的命名集合。构建目标将传入的构建请求映射到两个标签：构建标签（定义构建时可用软件包）和目标标签（构建产物最终存放位置）。Koji 不仅构建 RPM，还通过插件系统协调镜像构建，如 Kiwi 镜像、Image Builder 制品和 OSTree 组合。

门控更新：Bodhi

对于非 Rawhide 的分支版本，新构建的 RPM 需要通过 Bodhi 更新管理系统才能到达用户。Bodhi 通过反馈和测试周期来控制更新的发布。维护者提交包含一个或多个构建的更新，该更新会经历“待定”、“测试”、“稳定”等状态。用户和自动化测试提供“业力”（karma）评分。当更新获得足够业力或在测试阶段停留足够天数后，会被自动推送至稳定版。Bodhi 通过操作 Koji 标签来管理这一切，并在更新稳定后调用 Pungi 来组合更新仓库。

组合发布：Pungi

Pungi 是组合编排器，负责将单个 RPM 组合成可下载安装的 ISO、云镜像等。它协调其他工具，确保所有制品都基于同一组一致的软件包构建。

1. 冻结软件包集：Pungi 首先从 Koji 标签中快照软件包集。后续所有阶段都基于这个冻结的集合，确保组合过程可审计。
2. 决定内容归属：Pungi 通过两个 XML 输入文件决定哪些软件包属于哪个产品。comps 定义软件包组（如 gnome-desktop），variants XML 定义组合中的产品（如 Workstation、Server），并列出每个产品包含的 comps 组。
3. 构建启动镜像：Buildinstall 阶段运行 lorax 创建 boot.iso，这是启动 Anaconda 安装程序的镜像。
4. 生成 ISO：Createiso 阶段将 boot.iso 与软件包和仓库元数据结合，生成最终的安装 ISO（如 Server 的 dvd.iso）。
5. 使用 Kiwi 构建镜像：Kiwi 是 Fedora 组合中的主要镜像构建工具，用于构建云镜像、Vagrant 镜像、容器基础镜像、WSL 镜像以及大多数桌面衍生版的 Live ISO。它通过 Koji 插件集成，在 Mock 构建根中运行。
6. 使用 Image Builder 构建镜像：Image Builder 处理基于 ostree 和 bootc 的制品，如 Atomic Desktop ISO、Fedora IoT 等。它基于 osbuild 管道引擎，通过 JSON 清单描述构建步骤。它也通过 Koji 插件集成。
7. 构建 Atomic Desktop：rpm-ostree：Fedora Silverblue 等变体通过 rpm-ostree 构建。它生成一个版本化、带校验和的文件系统树（OSTree 提交）。Pungi 的 OSTree 阶段在 Koji 环境中为每个 Atomic Desktop 变体调用 rpm-ostree compose tree。
8. 组合元数据：每次组合都会生成一组元数据文件（如 composeinfo.json、images.json），描述组合内容。这些文件被 Anaconda、Bodhi、openQA 等下游工具使用。
9. 测试：openQA：组合完成后，openQA 自动测试系统会启动组合的镜像，在虚拟机中运行安装、桌面功能、升级路径等测试场景。测试结果用于发布验证。

典型流程

一个典型的 Fedora 组合流程如下：Pungi 首先初始化（解析 comps 和 variants XML），然后冻结软件包集。接着并行执行基础步骤（构建启动镜像、收集软件包仓库、构建 OSTree）。之后并行执行镜像生成步骤（创建 ISO、Kiwi 构建、Image Builder 构建）。最后计算校验和、写入元数据，并运行完整性测试。

治理：变更流程

对 Fedora 的重大修改，如新工具、默认设置变更或大规模重建，需要通过“变更流程”。该流程分为“系统级变更”和“自包含变更”，需要经过提案、审查和 FESCo（工程指导委员会）投票等环节。

根据评论内容，总结如下：

主要观点与论据：

1. 文档价值高：评论2（评分None）认为端到端文档对故障排查“invaluable”（无价），并举例Fedora版本间根文件权限问题因该文档得以定位。关键引用：“This kind of end to end documentation is invaluable when you're trying to troubleshoot.”（这种端到端文档在故障排查时非常宝贵。）

2. 构建环境可靠性：评论4（评分None）指出“clean room”构建并非绝对可靠，曾因依赖未在Build-Requires中声明而意外成功，但COPR的干净环境能暴露此类问题。关键引用：“a package happened to build only because, by happy accident, the builder had a dependency installed by something else.”（一个包之所以能构建成功，只是碰巧构建器因其他原因安装了某个依赖。）

3. 贡献入口需求：评论3（评分None）作为新用户询问Fedora贡献方向及志愿者需求清单。关键引用：“where would be a good place to look for areas to contribute in?”（哪里可以找到适合贡献的领域？）

4. 负面评价：评论6（评分None）批评IBM对Red Hat的“bluewashing”（漂白）行为，并引用外部链接。关键引用：“Meanwhile the bluewashing seems to be keeping a steady pace.”（与此同时，漂白行为似乎稳步推进。）

平衡性说明：正面观点（文档价值、构建环境讨论）与负面观点（IBM影响）并存，但正面评论更具体且与主题直接相关。