跳至内容

Rocky Build Process Overview (Revised)

更新 2：本文档的更新版本于 2021-01-04 发布，已完成大量概念性工作，许多事情已最终确定

这是一份简单的文档，解释了如何从 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 仓库，并分发给用户


显然，每个步骤都包含更多内容。本文档不会深入探讨完成每个步骤的方法和途径。我们希望尽可能自动化每个步骤。我们将逐一（简要）介绍每个步骤，以及可用于实现它们的各种选项。


第一步：获取源码

这相当直接。如果您想重新构建 RHEL 8，您需要 RHEL 8 的源码。有 2 种主要方法可以做到这一点：

  • 通过 RHEL 机器上的 yum/dnf 下载源码 RPM 文件
  • 从 https://git.centos.org 复制（它们与 RHEL 相同，并带有版本标签）

打包团队已决定采用选项 #2：从 CentOS Git 复制。这最大限度地减少了与 RHEL 订阅条款相关的潜在法律问题，并且是一项简单的操作。如果 CentOS Git 站点出现任何问题，将来也可以使用 SRPM 提取。

目前正在开发工具以自动化此步骤。CentOS（和 Fedora）使用 MQ 消息解决方案来指示何时向存储库提交了新提交。我们打算也使用这些已发布的 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 本身使用的“lookaside 缓存”机制。所使用的机制称为 dist-git，它涉及一个单独的脚本，用于下载与已签出的 Git 分支匹配的 tar 文件。

如果此方法不起作用，git-lfs 也是二进制存储的流行选项。

Git 中的文件/文件夹、标签/分支布局：

我们应该遵循 git.centos.org 的文件夹/标签/分支布局吗？还是完全不同的布局？我们应该将去除品牌标识的元数据与项目一起存放，还是放在其他地方？自动化/脚本化的测试用例怎么样？有很多事情需要考虑。

暂定答案：我们的 Git 布局可能会镜像 git.centos.org 中某些软件包的分支，但使用不同的名称。去除品牌标识的元数据将分开存放，与模块化软件包构建相关的元数据也将分开存放。


第四步：生成 Rocky Linux 源码 RPM

一旦进入 Rocky 仓库，软件包的内容应该直接对应于其 SRPM 等效项。

到此时，去除品牌标识应该已经完成，因此构建系统（Koji）将能够指向该仓库，获取其源码，并使用 Mock 和其他 RPM 工具构建我们的 Rocky SRPM。

必须特别注意 RHEL 8 中的“模块化/流” RPM。需要正确设置与 Koji 交互的模块化构建系统 (MBS) 服务以适应这一点。

构建配置的细节将取决于上述步骤 2-3 的答案：内容将放在哪个文件夹，二进制 tar 文件数据将位于何处，等等。


第五步：生成 Rocky Linux 二进制 RPM

这相当直接。一旦我们拥有有效的源码 RPM，我们就使用构建系统来提取、编译并生成有效的二进制 RPM。

同样，模块化/流软件包和依赖项需要特别考虑。

关于依赖项的说明： RHEL 中构建软件包所需的所有东西并不都可用。某些软件包需要先构建其他软件包，并在另一个软件包能正确编译之前生成其 **-devel** 软件包。RHEL/CentOS 没有维护这些“额外”依赖项的公共位置，但 Rocky Linux 计划这样做。稍后可能会有另一份文档详细说明这些信息。

完成后，我们就可以进行测试、签名，然后将其发送到官方仓库（和镜像！）。


第六步：签名和测试

我们生成的 RPM 应使用 Rocky Linux 密钥进行加密签名，这向用户保证该软件包确实是由 Rocky Linux 项目构建的。

软件包还需要经过一些测试 - 最好是自动化的。测试的性质尚待确定，但我们在将其发布到世界之前，至少需要进行一些基本检查。（该软件包是否可以安装？我们是否意外遗漏了任何文件？它是否会导致 dnf/yum 依赖冲突？等等）


第七步：部署到仓库

一旦软件包完成并通过测试，它将被上传到 Rocky Linux 仓库，并被全球仓库镜像网络拾取/克隆。Rocky 8 源码 RPM 当然也会被上传。

然后，发行版的用户在运行 dnf update 或 dnf install 时就能看到它！


结束语：

这是本文档的“第三版”。我们现在已经进入项目大约一个月，并且在我们的理解上已经取得了长足的进步！

研究这些技术问题的技术人员在短时间内学到了很多东西，并且已经有了可用的概念验证 RPM 管道（！）。来加入我们在 Mattermost 上的 ~Dev/Packaging 频道，我们很乐意讨论软件包/发布管道的方向。

仍然有几个问题需要回答，特别是在步骤 2-3 方面。不过，进展正在取得。

明确需要做什么比实际完成它要容易得多。

随着更多技术信息的到来，本文档仍然是一个正在进行中的项目。

本文档仍然是一个草稿，随着我们了解更多信息，可能会进行更多修订。


谢谢，

-Skip Grube (Mattermost) (IRC 上的 skip77)