生产环境配置一样，每次都需要重新编译软件包，太费时间了，制作成rpm包，搞好依赖，瞬间搞定
这里使用rpmbuild来制作rpm包
rpmbuild默认工作路径由%_topdir的宏变量来定义，这个变量在/usr/lib/rpm/macros里的定义。也可使用rpmbuild命令查
rpmbuild --showrc |grep _topdir 结果如下：
-14: _builddir %{_topdir}/BUILD
-14: _buildrootdir %{_topdir}/BUILDROOT
-14: _rpmdir %{_topdir}/RPMS
-14: _sourcedir %{_topdir}/SOURCES
-14: _specdir %{_topdir}/SPECS
-14: _srcrpmdir %{_topdir}/SRPMS
-14: _topdir %{getenv:HOME}/rpmbuild
如果想更改这个目录，在用户家目录下建立一个名为.rpmmacros的隐藏文件，然后在里面重新定义%_topdir，指向一个新的目录名，一般不推荐直接改/usr/lib/rpm/macros文件
制作rpm包的目录结构：
目录名 说明 macros中的宏名
BUILD 编译rpm包的临时目录 %_builddir
RPMS 最终生成的rpm包的所在目录 %_rpmdir
SOURCES 所有源代码和补丁文件的存放目录 %_sourcedir
SPECS 存放SPEC文件的目录(重要) %_specdir
SRPMS 源码格式rpm包存放路径 %_srcrpmdir
这些目录不需要手动创建，直接
yum install rpmdevtools -y
rpmdev-setuptree
用tree命令查看：
$ tree rpmbuild/
rpmbuild/
├── BUILD
├── RPMS
├── SOURCES
├── SPECS
└── SRPMS
就可以看到目录已经建好了
rpmbuild选项
制作rpm包，最重要的是写spec文件，还要注意 一句最重要的话：
分离程序：应用程序的源代码发布时，通常会捆绑许多外部依赖库的源代码。请不要将外部组件与主程序一起打包。相反，您需要拆分每个组件并单独打包。
几个重要概念：
※注意区分$RPM_BUILD_ROOT和$RPM_BUILD_DIR：
$RPM_BUILD_ROOT是指开头定义的BuildRoot，而$RPM_BUILD_DIR通常就是指/usr/src/asianux/BUILD，其中，前面的才是%file需要的。
1 rpm打包过程中容易混淆的两个概念:
build directory: 是rpmbuild实际软件构建,编译源码,运行脚本等的地方.通常你不用担心构建目录,因为rpmbuild命令会按需要自动切换到合适的目录,通常的build directory根目录是BUILD.
buildroot: 是用于测试安装的目录.通常是/var/tmp目录. rpmbuild会在buildroot目录下执行spec文件的install段,模拟将来rpm包在客户机上的安装过程,其中/var/tmp目录就是客户机上的根目录.这样,通过观察buildroot目录下的文件即目录结构,你就可以看到将来rpm包将会在客户机上安装哪些文件.
你应当总是在spec文件中通过定义Buildroot项去设置buildroot:
Buildroot : %{_tmppath}/%{name}-%{version}-root
上面的例子中将buildroot设置在由宏_tmppath指定的临时目录下.(_tmppath宏在/usr/lib/rpm/macros文件中定义,通常就是/var/tmp).
一旦你设置了buildroot后,你就可以在spec文件中通过RPM_BUILD_ROOT环境变量来访问它.
2 %setup宏
在%prep段,你大部分情况都可以通过运行%setup宏来完成工作.这个宏会将目录切换到build directory目录下,然后解压缩SOURCES目录下的压缩包源文件(setup宏支持大部分压缩包格式,如tar,zip,gzip等).
*%setup宏期望它解压的源文件压缩包能生成一个具有压缩包名加上类型组成的名字的目录.如果源文件包解压缩后的文件并没有如此组织,可以通过-c选项创建一个这样的顶层目录并且可以通过-n选项指定名字.期望这样一个顶层目录和名字的原因是为了把所有的需要的源文件放在同一个目录下,避免和其他包的源文件冲突(你当然不要期望每个时刻只有你一个人正在进行rpm打包).
3 不要在windows环境编辑spec文件,即使是记事本都不行.因为windows下的编辑器会向spec文件中添加控制字符.使得spec文件在被rpmbuild运行时,生成的临时脚本文件因为spec中的控制字符而出现类似"^M"这样的符号,导致打包失败.
%pre %post %preun %postun
当升级时，完整的执行流程如下：
1、执行新包spec文件中 %pre 段.
2、安装新包的相关依赖包.
3、执行新包spec文件中的 %post 段.
4、执行旧包spec文件中的 %preun 段.
5、删除新包中不需要的旧文件。
6、执行旧包spec文件中的 %postun 段.
参考文档：http://hlee.iteye.com/blog/343499
https://yq.aliyun.com/articles/27261