rpmbuild的简化工作流程

用一个简化的流程来看 rpmbuild 是怎么工作的：

1. 准备源码：把 .tar.gz 源码包放到 SOURCES 目录。
2. 解压编译：rpmbuild 会把源码解压到 BUILD 目录，并在那里执行 make 编译出二进制文件。
3. 模拟安装（关键点）：这是 %install 阶段。rpmbuild 不会把编译好的文件直接装到系统的 /usr/bin 下，而是装到一个构建根目录里。这个目录就是 BUILDROOT，它模拟最终用户的根目录结构（类似一个空的 chroot 基础目录）。
   • 例如：编译出的程序本来是装在 /usr/bin/myapp，那么在 %install 阶段，它实际会被安装在 BUILDROOT/usr/bin/myapp。
4. 收集并打包：rpmbuild 根据 .spec 文件里的 %files 列表，去 BUILDROOT 目录里把对应的文件抓取出来，压缩成 .rpm 包。
5. 输出结果：生成的二进制包最终放到 RPMS 目录（如果是源码包则放到 SRPM 目录）。

其中：

• RPMS 目录：存放生成的二进制包（如 xxx.rpm）。
• SRPMS 目录：存放生成的源码包（如 xxx.src.rpm）。

在 rpmbuild 的构建过程中，一个软件工程往往不仅仅是生成一个包，它可能会生成主包（如 nginx）、子包（如 nginx-devel、nginx-utils、nginx-mod-http-ssl）等等。这些多个二进制 RPM 包，都会统一存放在 RPMS 目录下。而且，RPMS 目录下通常会按架构再分子目录存放，比如：

• RPMS/x86_64/
• RPMS/aarch64/
• RPMS/noarch/（存放与架构无关的包）

SRPMS 目录专门用于存放源 RPM（Source RPM，简称 SRPM），扩展名是 .src.rpm。它通常包含：原始的 .tar.gz 源码包、.patch 补丁文件、以及构建用的 .spec 文件。

两者的区分在标准 rpmbuild 目录树中的定义：

• ~/rpmbuild/RPMS/：存放打包后生成的二进制包（Binary RPMs，扩展名为 .rpm）。
• ~/rpmbuild/SRPMS/：存放打包后生成的源码包（Source RPMs，扩展名为 .src.rpm）。

那为什么 SRPM 还需要打包？因为 tar.gz 只是源代码，而 SRPM 是“可复现构建的完整配方包”。两者的本质区别在于：

tar.gz 里通常只有上游作者发布的原始代码，它不知道如何在你的系统上变成一个 RPM 包。而 SRPM（.src.rpm）是一个包含了所有构建必需品的容器，通常包含：

• 原始源码（就是你准备的那个 tar.gz）
• .spec 文件：这是灵魂，定义了依赖关系、编译选项、安装路径、打包规则、changelog 等。
• 补丁文件（.patch）：发行版维护者为适配系统或修复问题而打的补丁。

简单说，tar.gz 回答的是“代码是什么”，SRPM 回答的是“如何在这套 RPM 体系里，把这些代码变成可安装的包”。如果只给 tar.gz，别人还得自己写 spec、猜编译参数、找补丁，无法保证构建结果一致。SRPM 让整个构建过程可审计、可重现。