模拟构建指南
标题：构建顺序工作：如何帮助¶
如果您有兴趣帮助 Rocky Linux 打包工作，我们很乐意为您提供帮助！我们需要完成的一项关键工作是弄清楚软件包需要按什么顺序构建，并确定任何外部/外部构建依赖项。阅读更多内容以了解我们的意思
需要做什么？¶
RHEL/CentOS 中的许多源软件包无法自行正确构建。通常，您需要先构建其他软件包并生成一些 RPM 作为依赖项。
我们的使命：是通过识别这些依赖项链并确定我们需要按什么顺序构建来帮助发布工程团队。此外，我们需要识别软件包构建所需的任何外部依赖项。所有这些信息都必须记录下来，以便我们能够构建 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 上跟踪此工作的成果。如果您单击左上角的“浏览”，然后导航到开发 -> Build_Order，您将看到许多引用“构建过程”的页面。
构建过程非常简单
- 使用 mock 尝试构建 CentOS 中的所有 ~3000 个软件包，仅使用默认的 BaseOS、AppStream 和 PowerTools 仓库。
- 记录哪些软件包已通过构建，哪些软件包构建失败。以及执行构建过程后生成的 RPM 文件。（这就是这些 Wiki 页面中的内容）
- 获取生成的 RPM 并将其添加到仓库中，以便下一个构建过程可以使用它们作为依赖项。
- 再次执行！（一次又一次……）
- 一旦我们构建了所有内容，我们将使用这些页面作为参考。我们现在知道需要按什么顺序提供这些内容
幸运的是，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 频道中闲逛，随时倾听！请 ping @Skip Grube 或 @Michael Young 并告知您如何解决的！我们会尽快将其添加到我们的知识库中，谢谢！