打包rpm软件包之spec文件解析
1. 概述
RPM的全称是（Red Hat Package Manager，Red Hat包管理器）。RPM是一个开放的软件包管理器，工作在Red Hat、类Linux和其他Unix系统上，可以被任何用户来使用。RPM的发布基于GPL协议。对于最终用户安装、卸载、升级RPM软件包，只需执行执行一条命令即可。RPM维护了一个所有已安装的软件包和文件的数据库，可以让用户进行查询和验证工作。在软件包升级过程中，RPM会对配置文件进行特别处理，绝对不会丢失以往的定制信息。
2. 编译安装软件的步骤
在介绍SPEC文件之前，我想先整理一下编译安装软件时的工作步骤。
将上面系列步骤进行进一步整理，可以归纳出下面几个步骤
- 准备阶段：下载源码文件、解压到执行的工作目录
- 配置安装依赖：安装
gcc等编译器，并解决相关依赖 - 编译阶段：运行
configure执行相关配置，配置完以后再执行make命令进行源代码编译 - 安装：执行
make install执行安装阶段 - 配置主机环境：设置环境变量、配置
service脚本 - 配置软件环境：修改配置文件
- 启动软件
既然我们了解了编译安装软件的步骤，那么接下来就可以进入正题了。一起讨论一下RPM软件包，RPM包分为两种：1、binary格式，2、source格式。binary格式的RPM软件包包含的是二进制格式软件包，直接解压安装即可，不需要再本地进行编译，source格式的软件包则包含的是源码文件，在本地仍然需要进行编译后才能使用。简单的来说binary格式的RPM包需要在你的机器上再运行编译安装过程中的3、4步骤，因为打包的作者已经帮你搞定了，相对而言source格式的RPM包需要在你的机器上进行编译。
现在大家应该已经大致了解了RPM包的打包过程。可以将打包过程看是对编译安装操作的一种封装，通过RPM包可以让用户抛弃编译安装时的繁琐步骤，直接关于软件自身的功能。
Linux本身提供了一种工具rpmbuild，可以让软件包作者更为方便的构建RPM软件包。既然rpmbuild是一种工具，那肯定就会存在一种对应的描述语言，让rpmbuild知道构建RPM软件包的整个过程。这种语言就是SPEC啦。接下来，将会介绍SPEC。
3. .SPEC文件
这个文件中包含了软件包的诸多信息，如软件包的名字、版本、类别、说明摘要、创建时要执行什么指令、安装时要执行什么操作、以及软件包所要包含的文件列表等等。大致来说SPEC文件分为：1、文件头，2、%prep段、3、%build段，4、%install段，5、%check，6、%file段，7、Scriptlets。接下啦将对每段进行详细介绍。
3.1 文件头
RPM包的一些描述信息，在运行yum info命令时，显示的正是此信息。文件头主要包含以下几个域，我经常将他们分为两部分。第一部分主要是该软件包的描述信息，可以通过yum info进行查看。第二部分主要是rpm打包时、程序运行时的描述，指定源代码、补丁、依赖环境等信息。
- 第一部分
| 域 | 含义 |
|---|---|
| Name | 软件包名称 |
| Version | 软件版本 |
| Release | 软件包释放号 |
| Summary | 软件包的概括信息，让用户快速了解该软件包的功能 |
| Vendor | 软件开发者名字 |
| License | 软件包所采用的协议 |
| Group | 软件包所示类别 |
| URL | 该软件包的项目主页 |
| %description | 软件包详细说明 |
- 第二部分
| 域 | 含义 |
|---|---|
| Source | 源程序软件包的名字 |
| Patch | 源码的补丁文件 |
| BuildRequires | 编译软件包时所需的依赖包列表，以逗号分隔。此标签可以多次指定。 |
| Requires | 安装软件包时所需的依赖包列表，以逗号分隔。是安装/运行程序时所需的依赖 |
| BuildArch | 如果你要打包的文件不依赖任何架构，请使用BuildArch: noarch。RPM 架构会变成noarch |
3.2 %prep段
prep就是prepare的简写嘛。所以大家伙都看出来呀，这个是准备阶段嘛。这个阶段执行的工作与编译安装时的第一个阶段差不多，都是一些解压源码文件、打补丁之类的。
这个阶段可以使用%autosetup命令自动完成解压源码、打补丁的工作。也可以通过%setup和%patch命令自己进行解压源码文件和打补丁。其中%setup具有以下几个参数选项:
-n：如果源码包解压后的目录名称与 RPM 名称不同，此选项用于指定正确的目录名称。-c：如果源码包解压后包含多个目录，而不是单个目录时，此选项可以创建名为 name 的目录，并在其中解压-q：应该是quiet的简写，抑制不必要的输出
示例
# 示例 1使用%autosetup
...
%prep
%autosetup
...
# 示例 2使用%setup %path
...
%prep
%setup -q
%patch -p1
%patch1 -p1
...
3.3 %build段
build不是建立、构造的意思么。所以这一段就相当于执行了编译安装中的第三步喽。想一想在编译安装过程中我们在这一步执行了什么操作嘞？
./configure
make
在%build段中同样也执行这些操作嘛。因为很多程序都默认使用GUN configure进行配置，所以rpmbuild工具就提供了一个%configure宏来自动设置配置选项，如修改前缀为/usr，共享库为/usr/lib或者/usr/lib64。当然你也可以自己执行编译的相关命令啦。
示例
# 示例1 使用%configure
...
%build
%configure
make %{?_smp_mflags}
...
# 示例2 自定义
...
%build
./configure --prefix=/usr
make -j4
...
3.4 %install段
install的意思是啥嘞？安装。对了，就是安装。着一段执行的就是安装操作。不过和编译安装时有些不同，在编译安装时使用make install命令，就真的把程序安装到系统上了，而在这里只是将程序安装到rpmbuild的虚拟目录（文件系统）中。另外还想说明的一点是，%install段中的命令只在创建RPM包的时候会运行，在安装RPM包的时候不会执行该段的任何命令。
本阶段包含安装阶段需要执行的命令，即从%{_builddir}复制相关文件到%{buildroot}目录（通常表示从~/rpmbuild/BUILD复制到~/rpmbuild/BUILDROOT)目录，并根据需要在%{buildroot}中创建必要目录。
示例
%install
rm -rf %{buildroot}
%make_install
3.5 %check段
这一段主要是执行测试的功能，如:
%check
make test
...
3.6 %file段
这一段相对来说就好玩多了，凡是使用编译安装方法安装过软件的兄弟们可能对上面的一些操作不以为然，认为这命名都是一些编译安装时的所执行的指令嘛，所谓的rpmbuild .spec到底神奇在哪呢？我个人认为神奇点就是这一段，对，就是%file段。接下来我们看看这一段有啥好神奇的。
首先，我们了解一下这个段的功能是啥？%file段的功能是指定需要被打包的文件和目录，也就是说该段指定将哪些文件和目录打包到rpm中。那么各位可能又得问了，打到RPM包中有什么意思呢？哈哈，意思可就大多啦。将文件和目录打包到rpm中，在解压时，直接按照对应的目录，将rpm包中的文件和文件夹复制到文件系统中，这不就完成程序的安装了嘛，so easy。
文件主要分为三类：1、说明文档（doc） 2、配置文件（config）3、执行程序。在该段中还有一些特殊指令和有用的宏。其中指令有：
*. %defattr 用于设置默认文件权限
# %defattr(<文件权限>, <用户>, <用户组>, <目录权限>)
# - 表示默认权限
%defattr(-,root,root,-)
*. %config 用于管理配置文件
# noreplace可以保证在更新软件时，如果已经存在foo.conf配置时，则不会替换该文件
%config(noreplace) %{_sysconfdir}/nginx.conf
# 允许替换配置文件
%config %{_sysconfdir}/nginx.conf
*. %attr 用于文件权限的精确配置
# %attr(mode, user, group)
# - 表示默认权限
%attr(0644, root, root) FOO.BAR
*. %caps 用于为文件分配 POSIX capabilities，我没看懂，就不误导大家了
# %caps(capabilities)
%caps(cap_net_admin=pe) FOO.BAR
宏
| 宏 | 含义 |
|---|---|
| %{_sysconfdir} | /etc |
| %{_prefix} | /usr |
| %{_exec_prefix} | %{_prefix} |
| %{_bindir} | %{_exec_prefix}/bin |
| %{_libdir} | %{_exec_prefix}/%{_lib} |
| %{_libexecdir} | %{_exec_prefix}/libexec |
| %{_sbindir} | %{_exec_prefix}/sbin |
| %{_sharedstatedir} | /var/lib |
| %{_datarootdir} | %{_prefix}/share |
| %{_datadir} | %{_datarootdir} |
| %{_includedir} | %{_prefix}/include |
| %{_infodir} | /usr/share/info |
| %{_mandir} | /usr/share/man |
| %{_localstatedir} | /var |
| %{_initddir} | %{_sysconfdir}/rc.d/init.d |
| %{_var} | /var |
| %{_tmppath} | %{_var}/tmp |
| %{_usr} | /usr |
| %{_usrsrc} | %{_usr}/src |
| %{_lib} | lib (lib64 on 64bit multilib systems) |
| %{_docdir} | %{_datadir}/doc |
| %{buildroot} | %{_buildrootdir}/%{name}-%{version}-%{release}.%{_arch} |
| $RPM_BUILD_ROOT | %{buildroot} |
3.7 其他参数
后续在补充吧
4. 示例
接下来将以打Nginx的rpm包为示例。
GitHub