跳至内容

Mock building guide

标题：构建顺序工作：如何提供帮助

如果您有兴趣为 Rocky Linux 打包工作提供帮助，我们需要您的加入！我们急需完成的一项关键工作是找出软件包需要构建的顺序，并确定任何外部/第三方构建依赖项。请继续阅读，了解我们的意思。

需要做什么？

RHEL/CentOS 中的许多源代码包无法自行正确构建。通常，您需要先构建其他软件包，使它们可用作依赖项，然后才能构建当前软件包。

我们的使命：是通过识别这些依赖链来帮助发布工程团队，并找出我们需要构建这些软件包的顺序。此外，我们需要识别软件包构建所需的任何外部依赖项。所有这些信息都必须记录下来，以便我们能够构建 Rocky Linux 的初始版本（基于 RHEL/CentOS 8.3）。

我们正在复制 CentOS 8.3（来自 CentOS 存储库）的完整副本，并在此过程中进行记录。


软件包依赖/故障类型

1：发行版内部的开发依赖

这些依赖项（通常采用“-devel”RPM 的形式）在标准的 CentOS 存储库（BaseOS、AppStream、PowerTools）中不可用，必须通过首先构建其他软件包来生成。例如，软件包 curl 需要 libmetalink-devel 才能正确构建。libmetalink-devel RPM 在默认存储库中不可用，您必须通过获取 libmetalink 源代码 RPM 并进行编译来生成它。

2：发行版外部的依赖

某些软件包在构建时需要 CentOS/RHEL 存储库中根本不存在的软件包。这些软件包必须被识别、编译成 RPM，并提供给我们的构建过程。幸运的是，这些“外部”依赖项都位于 https://git.centos.org 。可以使用正确的​​分支进行检出，并编译成 SRPM，然后编译成 RPM。

3：构建时故障

某些软件包在使用默认 Mock 构建设置时，会因其他原因无法构建。我们必须调查这些故障并找出解决方法。最重要的是，要记录下我们如何解决这些问题。

例如，与 Java maven 工具相关的某些 RPM 在没有 /etc/maven.conf 文件存在的情况下会拒绝构建。我们可以将 Mock 工具设置为创建一个空的 maven.conf 文件来规避此要求。我们需要记录下来，因为这是成功构建所需的额外步骤。


我们如何做到这一点？

现代 RPM 软件包的构建是通过 mock 构建工具完成的。（ https://github.com/rpm-software-management/mock ）Mock 会创建一个空的 chroot 环境，并在其中安装一个最小化的系统。然后，它会在 chroot 环境中使用经典的 rpmbuild 工具构建源代码 RPM。

这确保了只有实际构建过程所需的软件包才会存在，并且不会意外地引入额外的依赖项。

使用和安装 Mock

Mock 是一个用 Python 编写的简单工具，并且非常普及。它在 CentOS/RHEL 8 的 EPEL 存储库中可用，甚至在一些基于 Debian 的发行版中也可用。我们在此研究构建中使用的是 **Mock 版本 2.6**（EPEL 8 中的默认版本）。

Mock 的使用非常简单：mock -r /etc/mock/myconfig.cfg --nocheck --resultdir=/path/to/results curl-7.61.1-14.el8.1.src.rpm

Mock 的配置文件允许您指定要在最小 chroot 环境中包含的内容，以及 DNF 在设置构建时将使用的存储库。幸运的是，我们有一个标准化的 mock 配置，您可以下载并自行使用（链接如下），这样您就不必从头开始设置所有内容。

构建期间，日志文件将写入您的结果路径。如果构建成功，生成的 RPM 也将存在于该路径中。


阅读 Mock 输出

Mock 在每次构建期间会生成具有标准/一致名称的日志文件。我们最关心的文件是：root.log 和 build.log。

Root.log 详细说明了用于设置 chroot 环境的过程。它显示了执行的命令，特别是安装的软件包。当 mock 尝试 dnf install 一个依赖项但找不到它时，通常会在此处显示缺失的依赖项。

Build.log 详细说明了实际的软件包构建过程。这包括了所打包软件（C、C++、Java、Rust 等）的编译步骤。它还包括 .spec 文件中概述的任何其他步骤/脚本。与依赖项无关的构建故障通常会出现在这里。


我们正在 Wiki 上跟踪这项工作的结果。如果您点击左上角的“浏览”，然后导航到 **开发** -> **构建_顺序**，您将看到许多提及“构建传递”的页面。

一个构建传递非常简单

  1. 使用 mock，仅使用默认的 BaseOS、AppStream 和 PowerTools 存储库，尝试构建 CentOS 中的所有约 3000 个软件包。
  2. 记录哪些软件包通过了，哪些软件包构建失败。以及构建传递生成的 RPM 文件。（这就是那些 wiki 页面中的内容）
  3. 获取生成的 RPM，并将它们添加到存储库中，以便下一个构建传递可以使用它们作为依赖项。
  4. 重复执行！（一遍又一遍……）
  5. 一旦我们构建了所有内容，我们将使用这些页面作为参考。现在我们知道需要以什么顺序输入这些软件包。

幸运的是，Skip Grube 有一台服务器并正在执行这些构建传递。我们需要帮助来排查单个软件包的问题。继续阅读...


我们需要帮助的地方：

我们已经进行了足够的构建传递，现在大部分（但不是全部）依赖项都已排好顺序。我们需要调查剩余的失败软件包，并确定它们失败的原因。

我们必须回答诸如：软件包失败是因为它需要依赖项吗？是外部依赖项，还是将在某个构建传递中自动生成？它是由于其他错误而失败吗？


第 0 步：熟悉 Mock 构建工具及其配置。学习如何构建 SRPM，以及如何从 git.centos.org 检出分支，将它们转换为 SRPM，并使用 Mock 进行编译。

第 1 步：最新的构建传递（截至本文档）是 #10。因此，这是构建失败的列表：https://wiki.rocky-linux.cn/en/team/development/Build_Order/Build_Pass_10_Failure

选择一个进行调查，并确保它不在我们已经解决的软件包列表中：https://wiki.rocky-linux.cn/en/team/development/Package_Error_Tracking

第 2 步：您可以在此处查看该失败软件包的 Mock 构建日志：https://rocky.lowend.ninja/RockyDevel/MOCK_RAW/（按存储库和软件包名称排序）。

第 3 步：在调查完日志后，尝试在您自己的 mock 环境中自行构建该软件包。我们的确切 Mock 配置可在以下位置找到：https://rocky.lowend.ninja/RockyDevel/mock_configs/（按构建传递编号排序），SRPM 可从 CentOS 获取：https://vault.centos.org/8.3.2011/（按存储库排序）。

第 4 步：这是棘手的部分，涉及故障排除技能。软件包究竟为什么会失败？如何使构建成功？这可能需要查找依赖项，修改 SRPM 中的 .spec 文件，或调整 mock 选项。

第 5 步：如果您解决了某个问题，请告诉我们！请前往 chat.rockylinux.org 。我们在 #Dev/Packaging 频道，并且随时倾听！@Skip Grube 或 @Michael Young，告诉我们您是如何修复它的！我们会尽快将其添加到我们的知识库中，谢谢！