Rocky 构建流程概述（修订版）
更新 2：此文档的更新版本于 2021 年 1 月 4 日发布，已完成大量概念性工作，许多内容已最终确定。
这是一份简单的文档，解释了从 RHEL 源代码到新（重新）构建的 Rocky Linux 软件包的过程。它并非旨在过于技术化或具体化，而只是对有兴趣了解此流程如何工作的人员的介绍（和总体计划）。
步骤：从 RHEL 8 源代码到 Rocky 8 二进制软件包¶
1：通过 SRPM 或 CentOS Git 获取 RHEL 源代码
2-3：将 RHEL 源代码导入 Rocky Linux Git，替换源代码中的任何受保护的商标/品牌
4：从 Rocky Linux Git 存储库为软件包生成 Rocky 8 源代码 RPM，可能使用 Koji/MBS/Mock RPM 构建工具
5：使用构建工具将源代码 RPM 编译为 Rocky 8 二进制 RPM
6：以自动方式对 RPM 进行签名和测试
7：将其部署到 Rocky Linux 存储库，并分发给用户
显然，每个步骤都包含更多内容。本文档不会深入探讨完成每个步骤的方法和手段。我们希望这些步骤尽可能自动化。我们将依次简要介绍每个步骤以及实现这些步骤的各种可用选项。
步骤 1：获取源代码¶
这相当简单。如果要重新构建 RHEL 8，则需要 RHEL 8 的源代码。主要有两种方法可以做到这一点
- 在 RHEL 计算机上通过 yum/dnf 下载源代码 RPM 文件
- 从 https://git.centos.org 复制它们（它们与 RHEL 相同，并带有标记的版本）
打包团队已决定使用选项 #2：从 CentOS Git 复制。这最大程度地减少了与 RHEL 订阅条款相关的潜在法律问题，并且是一个简单的操作。如果 CentOS Git 站点出现任何问题，将来可以使用 SRPM 提取。
现在正在开发用于以自动化方式执行此步骤的工具。CentOS（和 Fedora）使用 MQ 消息解决方案来指示何时对存储库进行新的提交。我们打算同样使用这些发布的消息来获取警报，以便在我们需要构建新软件包时获得通知。
我们获悉，https://git.centos.org 将成为将来 RHEL 源代码的实际提交位置，因此我们应该与优秀的公司为伍！
**未来文档：**将会有另一篇文档详细解释 CentOS Git 分支中的内容、如何导航等。
步骤 2-3：将源代码导入 Git，并替换品牌¶
这是一个重大的技术问题，需要仔细考虑。
RHEL 中的每个软件包都应该有一个相应的 Rocky Linux Git 存储库专门用于它。例如：Rocky Linux 将拥有一个 bash 存储库、一个 python3 存储库、一个 python3-gpg 存储库等。**每个软件包一个 Git 存储库。**是的，这是很多 Git 存储库。
我们的基础设施团队的决定是使用（自托管）**Gitlab** 实例。
本节将概述正在考虑的一些主要技术障碍
第二个私有 Git？¶
由于商标问题，托管原始 RHEL 材料在法律上存疑。有几个选项
- 托管第二个私有 Git，其中包含等待去品牌化的原始 RHEL 源代码
- 在导入源代码的同时通过脚本或补丁去除品牌，并将结果放置到主公共 Git 存储库中
**暂定答案：**在导入的同时应用去品牌补丁似乎可行。因此无需单独的私有存储库。
Git 软件包/二进制文件策略¶
软件包以 spec 文件、补丁和上游/原始源代码（作为 tarball（.tar.gz、tar.bz2 等））的形式分发。文本文件在 Git 中足够简单，但存储这些上游 tar 文件的不同策略。
**答案：**商定的策略是使用旁观缓存机制，就像 Fedora 和 CentOS 本身一样。所使用的机制称为 dist-git，它涉及一个单独的脚本，该脚本下载与签出的 Git 分支匹配的 tar 文件。
如果此方法不可行，git-lfs 也是一种流行的二进制存储选项。
Git 中的文件/文件夹、标签/分支布局：¶
我们是否应该坚持 git.centos.org 中的文件/标签/分支布局？或者完全不同的东西？我们是否应该将去品牌元数据与项目一起放置，或者放置在其他地方？自动化/脚本化测试用例又如何呢？这里有很多需要考虑的事情。
**暂定答案：**我们的 Git 布局可能会镜像 git.centos.org 中软件包的某些分支，但名称不同。去品牌元数据将单独保留，以及与模块化软件包构建相关的元数据。
步骤 4：生成 Rocky Linux 源代码 RPM¶
一旦进入 Rocky 存储库，软件包的内容应直接对应于其 SRPM 等效项。
此时去品牌应该已经完成，因此构建系统（Koji）将能够指向存储库，获取其源代码，并使用 Mock 和其他 RPM 工具构建我们的 Rocky SRPM。
必须特别注意 RHEL 8 中的“模块化/流”RPM。与 Koji 交互的模块构建系统 (MBS) 服务需要正确设置以适应这一点。
构建配置的细节将取决于上面步骤 2-3 的答案：内容将位于哪个文件夹，二进制 tar 文件数据将位于哪里等。
步骤 5：生成 Rocky Linux 二进制 RPM¶
这非常简单。一旦我们拥有有效的源代码 RPM，我们就会使用构建系统提取、编译并生成有效的二进制 RPM。
同样，模块化/流软件包及其依赖项需要特别考虑。
**关于依赖项的说明：**并非构建 RHEL 中软件包所需的所有内容都可以在 RHEL 中获得。某些软件包需要先构建其他软件包，并在另一个软件包正确编译之前生成其**-devel** 软件包。RHEL/CentOS 没有维护这些“额外”依赖项的公共位置，但 Rocky Linux 计划这样做。以后可能会出现另一篇文档更详细地说明此信息。
完成后，我们就可以进行测试、签名并将其发送到官方存储库（和镜像）！
步骤 6：签名和测试¶
我们生成的 RPM 应使用 Rocky Linux 密钥进行加密签名，这保证用户该软件包确实是 Rocky Linux 项目构建的。
软件包还需要进行一些测试 - 最好是自动化的。测试的性质尚待确定，但至少在将其发布到全世界之前，我们希望进行一些健全性检查。（此软件包是否可安装？我们是否意外遗漏了任何文件？它是否会导致 dnf/yum 依赖冲突？等等）
步骤 7：部署到仓库¶
软件包完成后并经过测试后，它将被上传到 Rocky Linux 存储库，并由遍布全球的存储库镜像网络获取/克隆。当然，Rocky 8 源代码 RPM 也将被上传。
然后，发行版的用户在执行dnf update或dnf install时将看到它！
结束语：¶
这是本文档的“第 3 版”。我们现在已经开始该项目大约一个月了，并且在我们的理解上取得了长足的进步！
审查本文档的技术人员在短时间内学到了很多东西，并且已经有了可用的 RPM 管道概念证明（！）加入 Mattermost 上的 ~Dev/Packaging，我们很乐意讨论软件包/发布管道方向。
仍然有一些问题需要回答，特别是在步骤 2-3 方面。不过，正在取得进展。
将需要完成的事情说出来比实际完成它要容易得多。
随着更多技术信息的输入，本文档仍处于开发之中。
本文档仍为草稿，随着我们了解更多信息，可能会进行更多修改。
谢谢，
-Skip Grube (Mattermost) (IRC上的skip77)