RPM打包中__spec_install_post宏的工作机制说明

__spec_install_post的调用逻辑 #

__spec_install_post是rpmbuild工具内置的流程钩子，由rpmbuild在打包流程中自动调用，不需要在spec文件或自定义配置中显式声明调用。
你排查到的宏定义如下：

__spec_install_post:
    ...
    __os_install_post
    ...

__os_install_post:
    ...
    %{!?_debug_package:     /usr/lib/rpm/redhat/brp-strip %{_strip}
    /usr/lib/rpm/redhat/brp-strip-comment-note %{_strip} %{_objdump}
     }
    ...

rpmbuild的执行阶段是硬编码在程序逻辑里的，执行顺序固定为%prep -> %build -> %install -> 安装后钩子 -> 文件拆分打包 -> 生成元数据。其中__spec_install_post的执行时机刚好在%install段执行完毕、开始将buildroot内的文件打入各个RPM包之前，属于标准流程的固定环节，因此你在业务spec或自定义配置中找不到显式调用位置是正常情况。
你关注的二进制strip逻辑也在这个钩子链里：当未定义_debug_package宏（即关闭debuginfo包生成功能）时，钩子会自动调用brp-strip、brp-strip-comment-note两个RPM自带脚本，对buildroot内的二进制、动态库文件执行strip操作，裁剪符号表和冗余注释段来压缩包体积；如果开启了debuginfo包生成，这两个直接strip的步骤会被跳过，改由专门的debugedit流程先提取调试信息存入独立debuginfo包，再对主包内的二进制执行strip。

RPM宏体系零散的原因 #

RPM宏调用链看起来晦涩、存在大量独立叶子宏，是其设计机制决定的：

• 宏是分层加载、支持覆盖的：rpmbuild启动时会按优先级依次加载程序内置宏、系统级宏（/usr/lib/rpm/路径下各发行版维护的宏文件）、用户级宏（~/.rpmmacros）、spec文件内定义的宏，后加载的宏可以覆盖之前的定义。大量叶子节点宏是预留的自定义入口，比如你看到的_strip、_objdump就是独立抽出的配置项，用户需要调整strip参数、替换工具路径时，不需要修改整个后处理流程，直接重定义对应叶子宏即可生效。
• 双下划线开头的宏多为内部流程挂载点：以__开头的宏基本都是rpm本身或发行版预设的内部逻辑宏，不要求普通打包者显式调用。比如__os_install_post就是RedHat系发行版（RHEL、CentOS、Fedora等）预留的系统级后处理挂载点，除了strip逻辑外，还挂载了man手册压缩、无效.la文件清理、文件权限校验等通用构建后操作，发行版可以直接往这个宏里追加自定义逻辑，不需要修改rpmbuild的源码。

如果需要梳理宏调用链，可以直接用rpm自带的工具查询，不需要手动翻找配置文件：

• 查看宏最终展开的实际内容：执行rpm --eval "%{你要查的宏名}"，比如rpm --eval "%{__os_install_post}"可以直接输出当前环境下该宏展开后的所有执行命令
• 查看宏的定义来源和默认值：执行rpm --showrc | grep -A 10 "你要查的宏名"，输出会标注宏的定义位置和具体值

内容的提问来源于stack exchange，提问作者Kevin Chan