原文地址：http://blog.chinaunix.net/uid-21123336-id-1830527.html
一 RPM介绍
RPM 以前是Red Hat Package Manager 的缩写，本意是Red Hat 软件包管理，顾名思义是Red Hat 贡献出来的软件包管理；现在应该是RPM Package Manager 的缩写。在Fedora 、Redhat、Mandriva、SuSE、YellowDog等主流发行版本，以及在这些版本基础上二次开发出来的发行版采用； RPM包中除了包括程序运行时所需要的文件，也有其它的文件；一个RPM 包中的应用程序，有时除了自身所带的附加文件保证其正常以外，还需要其它特定版本文件，这就是软件包的依赖关系。
RPM可以让用户直接以binary方式安装软件包，并且可替用户查询是否已经安装了有关的库文件；在用RPM删除程序时，它又会聪明地询问用户是否要删除有关的程序。如果使用RPM来升级软件，RPM会保留原先的配置文件，这样用户就不用重新配置新的软件了。RPM保留一个数据库，这个数据库中包含了所有的软件包的资料，通过这个数据库，用户可以进行软件包的查询。RPM虽然是为Linux而设计的，但是它已经移值到SunOS、Solaris、AIX、Irix等其它UNIX系统上了。RPM遵循GPL版权协议，用户可以在符合GPL协议的条件下自由使用及传播RPM。
转载后补充：
通用性公开许可证(General Public License，简称GPL)。
GPL同其它的自由软件许可证一样，许可社会公众享有：运行、复制软件的自由，发行传播软件的自由，获得软件源码的自由，改进软件并将自己作出的改进版本向社会发行传播的自由。
GPL还规定：只要这种修改文本在整体上或者其某个部分来源于遵循GPL的程序，该修改文本的整体就必须按照GPL流通，不仅该修改文本的源码必须向社会公开，而且对于这种修改文本的流通不准许附加修改者自己作出的限制。因此，一项遵循GPL流通的程序不能同非自由的软件合并。GPL所表达的这种流通规则称为copyleft，表示与copyright(版权)的概念“相左”。
GPL协议最主要的几个原则：
1、确保软件自始至终都以开放源代码形式发布，保护开发成果不被窃取用作商业发售。任何一套软件，只要其中使用了受 GPL 协议保护的第三方软件的源程序，并向非开发人员发布时，软件本身也就自动成为受 GPL 保护并且约束的实体。也就是说，此时它必须开放源代码。
2、GPL 大致就是一个左侧版权（Copyleft，或译为“反版权”、“版权属左”、“版权所无”、“版责”等）的体现。你可以去掉所有原作的版权 信息，只要你保持开源，并且随源代码、二进制版附上 GPL 的许可证就行，让后人可以很明确地得知此软件的授权信息。GPL 精髓就是，只要使软件在完整开源 的情况下，尽可能使使用者得到自由发挥的空间，使软件得到更快更好的发展。
3、无论软件以何种形式发布，都必须同时附上源代码。例如在 Web 上提供下载，就必须在二进制版本（如果有的话）下载的同一个页面，清楚地提供源代码下载的链接。如果以光盘形式发布，就必须同时附上源文件的光盘。
4、开发或维护遵循 GPL 协议开发的软件的公司或个人，可以对使用者收取一定的服务费用。但还是一句老话——必须无偿提供软件的完整源代码，不得将源代码与服务做捆绑或任何变相捆绑销售。
二 RPM包分类
我个人认为rpm分为两大类，
1 二进制类包，包括rpm安装包（一般分为i386和x86等几种）和调式信息包等。
2 源码类包，源码包和开发包应该归位此类。
它们之间的关系是，最先我们按rpm打包要求改造软件项目源码，当符合要求之后就可以使用rpmbuild命令来生成不同的rpm包，同时生成的包之间版本是直接对应的，比如相同的源码包将生成完全相同的二进制rpm包。当你在网上查找rpm包时，一般你可以在RPMS目录中找到预编译的二进制包，而源码包则会在SRPMS目录内。
我们这里提到的RPM制作就是指改造软件源代码使之符合RPM打包要求的过程，这也可以等价为RPM源码包的制作过程，因为当你有了源码包就可以直接编译得到二进制安装包和其他任意包。
三 RPM包制作介绍
RPM包的制作，即是RPM源码包的制作。
这里我想说说RPM包工作的原理，这将有助于全面的了解RPM包管理系统的知识。
RPM是为解决源码包不易安装（需要编译）和软件包相互之间依赖（是RPM包管理器可以一定程度解决依赖问题）问题，它通过在探测源码包在build和install阶段的动作获得最终生成的需要安装的系统里的文件，并记录下一些必要的操作（比如安装完成后执行某项操作），然后把此组成为一个整体，当在用户安装此包时把前面获得的所有问题和记录的所有操作原原本本的作用的实际系统上。
为一个普通的源码打RPM包，需要下面一些操作：
首先需要对项目的Makefile作必要的改造以支持RPM打包操作（实际上此操作不是绝对的，SPEC文档和Makefile的是协调统一工作的，只要他们之间配合好了其他都无所谓，我们一般只是推荐大家尽量按行业标准规范操作而已）；
其次是针对当前项目撰写SPEC文档，SPEC文档包括了RPM打包过程的操作内容和新生成的RPM包的基本信息等，它的作用对象是打包程序rpmbuild。
四 RPM包制作过程
1 准备打包环境
fedora系统下使用如下命令安装rpmbuild
#yum install rpmbuild
rpmbuild的工作目录如下，
~/rpmbuild
~/rpmbuild/SOURCES
~/rpmbuild/SPECS
~/rpmbuild/BUILD
~/rpmbuild/RPMS
~/rpmbuild/RPMS/i386
~/rpmbuild/SRPMS
如果你的用户目录主目录下没有类似目录结构，你可以通过一个工具软件来自动配置和生成，如下。
＃yum install rpmdevtools
下了运行自动配置命令自动生成如上目录，并配置一些必要操作。
＃rpmdev-setuptree
rpmdev-setuptree命令默认将再当前用户主目录下创建一个RPM构建根目录结构，
如果需要改变次默认位置，可以修改配置文件:~/.rpmmacros中变量_topdir对应
的值即可。
一般rpmbuild会在当前用户的主目录下自动建立如上目录结构，如果在你对应用户的构建目录中没有自动建立如上目录，你可以通过手动方式建立。上面目录的使用是这样分配的，SOURCES放置打包资源，包括源码打包文件和补丁文件等；SPECS目录放置SPEC文档；BUILD打包过程中的工作目录；RPMS目录存放生成的二进制包，RPM包根据硬件平台不同分类，i386表示生成i386结构的包将存放在该目录下;SRPMS目录存放生成的源码包。
2 撰写SPEC文档
SPEC撰写是打包RPM的核心，也算是最难的一步，好在我们可以从参照一个简单的模板文件开始，在可以实现基本功能的基础上再一步一步的扩充文档内容，直至完全达到要求。下面是一个简单的SPEC文档，其中包括了一些说明信息（注：#后面的内容为说明信息），该SPEC文档是对一个测试的软件项目hellorpm写的，hellorpm软件包编译后仅有一个执行文件、一个手册文件和一个项目说文件。
hellorpm.spec文档的内容如下：
#软件包简要介绍
Summary: hellorpm is a test program。
#软件包的名字
Name: hellorpm
#软件包的主版本号
Version: 2.2.6
#软件包的次版本号
Release: 1
#源代码包，默认将在上面提到的SOURCES目录中寻找
Source0: %{name}-%{version}.tar.gz
#授权协议
License: GPL
#定义临时构建目录，这个地址将作为临时安装目录在后面引用
BuildRoot:%{_tmppath}/%{name}-%{version}-%{release}-root
#软件分类
Group: Development/Tools
#软件包的内容介绍
%description
The hellorpm program is a test.
#表示预操作字段，后面的命令将在源码代码BUILD前执行
%prep
#构建BUILD环境，将解压源码压缩包到BUILD目录
%setup -q
#BUILD字段，将通过直接调用源码目录中自动构建工具完成源码编译操作
%build
#调用源码目录中的configure命令
./configure
#在源码目录中执行自动构建命令make
make
#安装字段
%install
#调用源码中安装执行脚本
make DESTDIR=$RPM_BUILD_ROOT install
#文件说明字段，声明多余或者缺少都将可能出错
%files
#设置文件权限属性
%defattr(-,root,root)
#声明/usr/local/bin/hellorpm将出现在软件包中
/usr/local/bin/hellorpm
#声明并设置文件属性
%doc %attr(0444,root,root) /usr/local/man/man1/hellorpm.1
#同上，声明文档文件
%doc README
这个文档需要说明的一点：
BuildRoot:%{_tmppath}/%{name}-%{version}-%{release}-root
上面BuildRoot变量表示的是源码的临时按照目录，rpmbuild就是通过次目录获得将要按照到系统中的所有文件，而在SPEC文档后面make install 命令中的参数DESTDIR=$RPM_BUILD_ROOT即是对该参数的引用，这个参数将传给Makefile文件一告诉自动构建工具应该安装文件那里（实际上我再前文提到过的Makefile需要作一些改造以适应RPM的构建就包括此操作，你的Makefile文件中至少要知道在RPM构建过程中引用此参数的值去控制安装操作的目标）。
如上一个简单的SPEC文档撰写完成，下面把一个名为hellorpm-2.2.6.tar.gz的源码压缩文件放到
rpmbuild根目录下的SOURCES目录下（注，确保此归档文件解压后的目录为hellorpm-2.2.6，
否则会有问题）。
到此一个完整的rpm打包环境已经构建完成，下面我们就可以开始构建二进制和源代码RPM包。
3 构建RPM包
构建RPM包是有命令rpmbuild在SPEC的指导下完成。
开始构建操作，首先进入到当前用户的rpmbuild根目录（即上面提到的目录环境）。
#cd ~/rpmbuild/
执行如何命令，-ba表示build all，即生成包括二进制包和源代码包的所有RPM包，下来如果正常的话，rpmbuild将正常退出，同时在RPMS目录和SRPMS目录中将生成对应的RPM包。
#rpmbuild -ba SPECS/hellorpm.spec
这里仅仅介绍了一个最简单软件的最简单的RPM的打包操作过程，诸如带有共享文件的需要进行复杂配置的具有复杂依赖关系的等等的项目的打包以及后期的维护，包括补丁的制作我将在下来的时间完成补充更新，今天时间不早了，该休息了！
注：费了大半夜的功夫，搞出这么个令人不满意的文档，我思考着，这样做有多少意义呢？不敢重复发明轮子的，站到巨人的肩膀你才能看得更远，是这样吗？
是不是下周开始立个计划，每周至少翻译三篇fedora官网的文档给自己练练手。那糟糕的英语，唉！
参考资料：
http://www.linuxsir.org/main/?q=node/50 RPM 的介绍和应用（北南兄）
http://www.ibm.com/developerworks/cn/linux/management/package/rpm/part3/ 用 RPM 打包软件
http://hlee.javaeye.com/blog/343499 RPM包rpmbuild SPEC文件深度说明