mock构建私有rpm包的核心是确保可靠、可重复且不污染主机，其本质是通过chroot在定制化虚拟小系统中隔离构建；需明确目标发行版与架构、配置私有源镜像、准备spec与源码、执行带参数的mock命令，并接入ci/cd自动化流程。
用 mock 构建私有 RPM 包，核心不是“怎么打包”，而是“怎么让每次打包都可靠、可重复、不污染主机”。它本质是把构建过程从你的开发机上搬进一个干净的、按需定制的虚拟小系统里，避免“在我机器上能跑”这类问题。
明确目标发行版和架构
mock 不是通用打包器，它必须知道你要为哪个系统构建。比如你的私有软件要部署在 CentOS 7 x86_64 服务器上，那 mock 环境就必须严格模拟这个环境。配置文件（如 /etc/mock/centos-7-x86_64.cfg）里要写清楚：
- target_arch 设为 x86_64
- dist 或 releasever 明确设为 7
- yum.conf 或 dnf.conf 指向你私有仓库或可信镜像源（比如阿里云、清华源），而不是默认的官方源
准备私有源码与 SPEC 文件
mock 本身不写代码，它只执行构建指令。你需要提前准备好：
- 一个标准的 .spec 文件，里面定义了源码地址、编译步骤、依赖（BuildRequires）、安装路径和最终包信息
- 源码包（.tar.gz/.zip）或 SRPM（.src.rpm）。如果是源码，放在 ~/rpmbuild/SOURCES/；如果是 SRPM，直接传给 mock 命令
- 所有补丁、配置模板等辅助文件，也一并放入 SOURCES 目录，spec 中通过 %patch 或 %install 引用
执行构建并验证结果
构建命令很简单，但关键在参数控制：
- mock -r centos-7-x86_64 --rebuild your-package-1.0-1.src.rpm：这是最常用方式，自动解析依赖、安装、编译、打包
- --resultdir /path/to/output：指定输出目录，避免混在默认的 /var/lib/mock/.../result 里
- --no-clean：构建失败时保留 chroot 环境，方便进入调试：mock -r centos-7-x86_64 --shell
- 构建完成后，检查输出目录里的 RPM 文件是否签名（可用 rpm -qpi 查看元数据），再用 rpm -qpR 确认依赖项是否符合预期
接入自动化流程
mock 天然适合 CI/CD。例如在 Jenkins 或 GitLab CI 中：
- 把 mock 配置文件和 spec 一起纳入代码仓库
- CI 脚本中先安装 mock 和 rpm-build，再将当前用户加入 mock 组（usermod -aG mock $USER）
- 触发构建时，用 mock -r ... --rebuild 命令生成 RPM，再自动上传到你的私有仓库（如 Nexus、Artifactory 或简单 HTTP 目录）
- 配合 createrepo 更新仓库索引，下游服务器就能用 yum install 直接部署
