这几天想在Rocky Linux 9上配置一个PostgreSQL的开发环境，需要Bear（一款专为clang工具链生成编译数据库的工具。在clang项目中，JSON编译数据库用于记录单个编译单元的处理信息。借助该数据库，开发者能够轻松使用替代程序重新执行编译流程）这个工具，然而Rocky并没有提供Bear的rpm包，这也难不倒我，自己下载源码编译呗！一动手发现Bear依赖google的gprc，grpc又依赖protobuff,可恨的是Rocky下居然也没包含二者的开发包！考虑到后续很多地方都会用到这三个，所以干脆给它们打个rpm包算了，顺便我也学学rpm打包这项技能。经过一番折腾，在AI的帮助下总算搞定了，于是总结了下面这些内容，后续还会写几个具体的案例。
RPM 打包的核心是 .spec 文件，它是包含打包规则、软件信息、构建流程、安装配置的文本配置文件，所有生成 RPM 包的逻辑均定义于此。除了基础的配置选项，spec 文件还支持条件判断语法，可实现多架构适配、多发行版兼容等灵活配置。本文将系统拆解 spec 文件的核心选项，并详细说明条件判断（if/else）的用法，为 RPM 打包提供完整指南。

一、 基础信息类选项（必选，定义软件核心标识）

这类选项用于描述软件的基本信息，是 RPM 包的“身份标识”，大部分为必选项，确保 RPM 包的可识别性和规范性。

1.1 核心必选选项

1.2 补充描述选项

二、 构建依赖与运行依赖类选项

这类选项用于声明 RPM 包编译构建时所需的依赖和安装后运行时所需的依赖，确保打包过程顺利且软件安装后可正常运行。

2.1 构建依赖选项

2.2 运行依赖选项

三、 构建与安装路径类选项（宏定义）

这类选项多为 RPM 内置宏（也可自定义宏），用于指定编译、安装、文件存放的标准路径，遵循 FHS（文件系统层次结构标准），提高打包的规范性和可移植性。

四、 构建流程脚本段（定义编译、安装逻辑）

这类脚本段以% 开头，按固定顺序执行，用于定义软件的编译、安装、清理等构建步骤，是 spec 文件的核心执行逻辑。

五、 文件管理段（定义 RPM 包包含的文件）

%files 段用于指定最终生成的 RPM 包中包含的所有文件/目录，以及文件的权限、所有者等属性，%install%{buildroot} 必须与 阶段安装到 的文件路径完全一致，否则打包会失败。

5.1 核心语法

%files [选项]
# 文件/目录路径（基于 %{buildroot}，省略 %{buildroot} 前缀）
# 可使用 RPM 宏、通配符（*、? 等）

5.2 关键选项与说明

六、 安装/卸载脚本段（定义运行时执行逻辑）

这类脚本段在 RPM 包安装、升级、卸载的不同阶段执行，用于完成系统配置、服务启停、用户创建等附加操作，支持标准 shell 命令。

关键说明：脚本中建议添加>/dev/null 2>&1 || :，避免非关键错误导致安装/卸载失败。

七、 条件判断（if/else）用法（灵活适配多场景）

RPM spec 文件的 if/else 是 RPM 内置的宏条件判断语法，非普通 shell 脚本判断，核心用于实现多架构适配、多发行版兼容、功能按需编译等灵活配置，核心关键字为 %if、%else（可选）、%elif（可选）、%endif（必选，闭合条件块）。

7.1 核心语法格式

# 单分支判断
%if <条件表达式>
  # 满足条件时执行的配置/脚本/文件定义
%endif

# 双分支判断
%if <条件表达式>
  # 满足条件时的逻辑
%else
  # 不满足条件时的逻辑
%endif

# 多分支判断
%if <条件表达式1>
  # 满足条件1的逻辑
%elif <条件表达式2>
  # 满足条件2的逻辑
%else
  # 不满足所有前置条件的默认逻辑
%endif

关键说明：条件表达式前后无需加括号；条件块内可包含 spec 任意内容；%endif 必选；支持嵌套条件判断。

7.2 核心条件判断类型（常用场景）

7.2.1 基于系统架构判断（%{_arch} 宏）

通过内置宏 %{_arch} 获取当前构建系统的硬件架构（如 x86_64、aarch64、i386 等），实现不同架构的差异化配置。

常用表达式：

1. 精确匹配：%if "%{_arch}" == "x86_64"
2. 多值匹配：%if "%{_arch}" == "x86_64" || "%{_arch}" == "aarch64"
3. 反向匹配：%if "%{_arch}" != "i386"

# 不同架构指定不同的构建依赖或文件路径
%if "%{_arch}" == "x86_64"
  BuildRequires: some-lib-x86_64-devel
  %{_libdir}/x86_64-linux-gnu/xxx.so
%elif "%{_arch}" == "aarch64"
  BuildRequires: some-lib-aarch64-devel
  %{_libdir}/aarch64-linux-gnu/xxx.so
%else
  BuildRequires: some-lib-devel
  %{_libdir}/xxx.so
%endif

7.2.2 基于宏是否定义判断（%{?宏名} / %{!宏名}）

用于判断某个宏是否已定义，实现“可选功能”的开关配置，灵活度最高。

常用表达式：

1. %if %{?宏名}：宏已定义则条件为真
2. %if %{!宏名}：宏未定义则条件为真
3. 结合值判断：%if "%{?宏名}" == "开启值"

# 自定义宏 --with-ssl，控制是否编译 SSL 功能
%define with_ssl 1

%if %{?with_ssl}
  BuildRequires: openssl-devel >= 1.1.1
  %build
  ./configure --with-ssl %{nil}
%else
  %build
  ./configure %{nil}
%endif

# 判断系统是否为 systemd 系统
%if %{?systemd}
  %{_unitdir}/nginx.service
  Requires(post): systemd
%endif

7.2.3 基于发行版版本判断（%{rhel} / %{fedora} 宏）

通过内置宏判断系统发行版及版本，实现 CentOS/RHEL 不同版本（如 el7、el8、el9）或 Fedora 不同版本的兼容适配。

常用内置宏：

1. %{rhel}：CentOS/RHEL 主版本号（如 7、8、9）
2. %{fedora}：Fedora 版本号（如 38、39）
3. %{dist}：发行版标识（如 el7、fc39）

常用表达式：

1. 版本比较：%if %{rhel} >= 8
2. 精确版本：%if %{rhel} == 7

# 不同 CentOS/RHEL 版本的 Python 依赖差异
%if %{rhel} >= 8
  BuildRequires: python3-devel >= 3.6
  Requires: python3 >= 3.6
%else
  BuildRequires: python2-devel
  Requires: python2 >= 2.7
%endif

# 不同版本的系统服务配置差异
%if %{rhel} >= 7
  %post
  systemctl daemon-reload >/dev/null 2>&1 || :
  systemctl enable --now nginx >/dev/null 2>&1 || :
%else
  %post
  chkconfig --add nginx
  service nginx start >/dev/null 2>&1 || :
%endif

7.3 注意事项

• 语法严格性：%if/%else/%elif/%endif 关键字必须单独成行，否则解析失败；

• 宏的引号：字符串类型的宏（如%{_arch}）判断时建议加双引号，避免宏值为空导致语法错误；

• 嵌套限制：支持嵌套但层级不宜过深（建议≤3层），避免可读性差；

• 调试方法：通过 rpmbuild -bp --nodeps xxx.spec 预处理 spec 文件，查看实际生效的配置。

八、 其他辅助选项与总结

8.1 其他辅助选项

8.2 总结

RPM spec 文件的核心逻辑可归纳为“基础定义-依赖管理-构建执行-文件配置-灵活适配”五大模块，关键要点如下：

1. 基础信息：Name/Version/Release/Summary/License 是必选，定义 RPM 包身份；

2. 依赖管理：BuildRequires（构建依赖）、Requires（运行依赖）确保打包和运行完整性；

3. 构建流程：%prep（解压补丁）、%build（编译）、%install（安装到临时目录）按顺序执行；

4. 文件管理：%files 需与 %install 路径完全一致，通过 %config、%attr 等指定文件属性；

5. 灵活适配：条件判断（%if/%else）基于架构、发行版、宏定义实现多场景兼容，是复杂打包需求的核心工具。

   （注：文档部分内容由 AI 生成）