【编者的话】RPM（Red Hat Package Manager）是用于 Linux 分发版的最常见的软件包管理器。因为它允许分发已编译的软件，所以用户只用一个命令就可以安装软件。而RPM包的构建相当繁琐，并且对环境的要求比较高， 本文作者介绍了如何借助Docker来构建可以适用多个平台的RPM包。
在一个内部项目中，我一直在思考如何通过非CI工具/流程生成RPM包，我想手动生成RPM包，这样我可以测试它们是否能正常安装，并用于正常的冒烟测试（译者注：冒烟测试就是在每日构建完成后，对系统的基本功能进行简单的测试。这种测试强调功能的覆盖率，而不对功能的正确性进行验证）。
在我们的CI流程中，Docker算是个全能手，所以我也在想能否将Docker镜像和RPM结合起来。理想的情况下，让RPM与Docker集成， 这样，创建RPM包的过程其实就是在构建一个Docker镜像。基本上，RPM包的%prep部分的构建可以在一个特殊的Docker镜像中快速完成，然 后将生成的RPM包返回给主机。
这种方式的的优点在于，你的RPM包是在一个相对封闭且可再生的环境中构建的，所以你可以快速的为CentOS、Fedora、RHEL等其它系统构建RPM包。
我相信还有其它的一些变通方法也可以完成这样的工作，比如chroot之类的。但如果在RPM中内建这种打包机制（通过chroot/Docker或者别的容器技术抽象而来的系统来完成打包工作）的话，我想会更好。
由于我的项目还没有完成，所以我只是对我的想法进行了验证：简单构建一个包含依赖的镜像。
这是一个使用PBR生成版本 的Python项目。 首先我在build目录中生成一个tarball，然后得到生成的版本号，紧接着修改spec文件中的版本号，然后开始用新的tar包和spec文件构建 镜像。最后运行镜像，并挂载卷（Volume）到本地目录。当运行容器中的start.sh脚本之后，镜像就运行起来了。
start.sh相当简单。 它构建好RPM包后，以root身份把它拷贝到卷目录下， 还可以从主机上将它拷贝到output目录。我没有将它拷贝或者说更新到类似swift之类的对象存储系统，因为我还要在CI中使用它，所以就使用本地文件拷贝了。
在SPECS/project.spec以及 SOURCES/* 是标准RPM包需要的spec文件，源文件和patch文件。需要做的唯一一件事是定义
