Rpm打包原理详解
RPM详解——精选推荐
RPM详解概述RPM⽂件结构RPM包⽂件⼀般包含4部分：Lead、Signature、Header、Payloadlead----开头的标识部分，⽤于标识此份⽂件为⼀个RPM包Signature-----数字签名，通常包括针对头部的签名和针对载荷的签名Header--------头部，通常包括版权信息，版本号，包描述等信息；有时还包含⼀些特定的标签（Tag），⽐如PRE Tag就包含了rpm包在安装前需要执⾏的预安装脚本。
Payload-------载荷，包含实际安装的⽂件RPM命令安装及升级安装的⼀般步骤install a package, it goes through a number of steps:1.Checking the package and the files it wants to install2.Performing preinstallation tasks3.Uncompressing the files and placing them in the proper locations4.Performing post-processing tasks5.Updating the RPM DatabaseRPM数据库的相关⽂件位于/var/lib/rpm/⽬录下。
新安装@前⾯为⽤户名及密码，⽤户名uncljoe ，密码workers升级rpm -Uvh ⽆论软件包存在与否都执⾏升级或rpm -Fvh仅针对已安装的软件包进⾏升级升级时，RPM会对每个⽂件，⽐对三个版本的MD5校验值（old package file，current file，new package file）。
如果old package file与new package file的MD5校验值⼀样，但current file 不同，说明新⽼版本的⽂件是⼀样的，但管理员编辑过该⽂件（通常是⼀些配置⽂件），rpm 会保留current file（保留管理员的所做的配置），⽽不会⽤新包中的⽂件覆盖。
RPM打包技术和典型SPEC文件分析
7 + cd /usr/src/dist/BUILD
生成的文件会在刚才建立的RPM目录下存在。
2）只生成src格式的rpm包
rpmbuild -bs xxx.spec
生成的文件会在刚才建立的SRPM目录下存在。
3） 只需要生成完整的源文件
rpmbuild -bp xxx.spec
二．典型spec文件分析
通过第一部分的介绍，我们对软件包的管理及spec文件的一些细节应该掌控的差不多了，接下来通过分析kaffeine.spec（kaffeine是linux平台下的媒体播放器）文件来让读者朋友实践一回spec文件的规范和书写。
Kaffeine.spec文件内容如下：
%define debug_package %
1） 只生成二进制格式的rpm包
rpmbuild -bb xxx.spec
用此命令生成软件包，执行后屏幕将显示如下信息：（每行开头为行号）
1 Executing： %prep
2 + umask 022
3 + cd /usr/src/dist/BUILD
4 + exit 0
5 Executing： %build
（3）build段
本段是建立段，所要执行的命令为生成软件包服务，如make 命令。
（4）%install段
本段是安装段，其中的命令在安装软件包时将执行，如make install命令。
（5）%files段
本段是文件段，用于定义软件包所包含的文件，分为三类--说明文件（doc），设置文件（config）及执行程式，还可定义文件存取权限，拥有者及组别。
5、RPM包及打包和压缩命令
第五讲 RPM管理及文件打包和压缩一、rpm包1、rpm=redhat package managment 红帽子包管理器，已成为整个linux行业的包管理的标准；2、linux下的软件安装方式<1>源代码安装<2>rpm包安装3、rpm包安装的特点<1>优点：简单，方便，快捷<2>缺点：包的安装有依赖性4.rpm包的安装：<1>rpm包名的命名规则：xsnow-1.42-10.i386.rpm软件名-主版本号.次版本号-补丁次数.机型.rpm包补丁次数中：奇数表示测试版，偶数表示正式版；<2>安装rpm包：#rpm -ivh 包名.rpm升级安装：#rpm -Uvh 包名.rpm-U:表示如未安装就安装，已安装则升级；#rpm -Fvh 包名.rpm-F:表示只做升级，不做新装；可支持通配符安装：#rpm -ivh dhcp*<3>查看已安装的RPM包：#rpm -qa 包名*#rpm -qa |grep 包名参数：-q:query 查询 -a:all 所有<4>查看已经安装的RPM包产生的文件及存放路径#rpm -ql 已安装的包名<5>通过文件查询来源的包名#rpm -qf 文件名<6>查看RPM包的详细信息#rpm -qi xsnow-1.42-10<7>卸载已安装的rpm包#rpm -e 已安装的RPM包名注意：不支持通配符卸载；<8> --force 即使覆盖属于其它包的文件也强迫安装--nodeps 如果该RPM包的安装依赖其它包，即使其它包没装，也强迫安装。
二、打包、查看、解包、压缩文件和目录命令:tar1、对文件和目录的打包和压缩2、查看归档和压缩文件3、恢复归档文件和压缩文件三、压缩命令： gzip (gzip的压缩率高于bzip2)功能：用于压缩文件，不能压目录，先把目录打包，再压缩。
rpm包 二进制 结构体
rpm包二进制结构体摘要：1.RPM 包的概述2.RPM 包的二进制结构3.结构体的概念和应用4.RPM 包与结构体的关系正文：1.RPM 包的概述RPM（Remote Package Manager）包是一种用于在Linux 系统上进行软件安装、升级和卸载的打包管理工具。
它通过将软件及其依赖关系打包成一个或多个文件，实现了对软件的便捷管理。
RPM 包通常包含软件的源代码、编译选项、安装脚本等，使得用户可以方便地安装和使用软件。
2.RPM 包的二进制结构RPM 包的二进制结构是指RPM 包内部所包含的文件格式。
RPM 包中的文件通常分为两种类型：数据文件和控制文件。
数据文件包含了软件的实际内容，如源代码、可执行文件等；而控制文件则包含了关于这个软件包的元数据信息，如版本号、依赖关系等。
RPM 包的二进制结构遵循一定的规范，通常包含以下几个部分：- 头部信息：包括RPM 包的版本号、名称、大小等基本信息。
- 控制文件：包含软件的元数据信息，如版本号、描述、依赖关系等。
- 数据文件：包含软件的实际内容，如源代码、可执行文件等。
- 差分数据：记录RPM 包的更新历史，用于计算软件包的更新差异。
3.结构体的概念和应用结构体是一种复合数据类型，用于将不同类型的数据组合在一起。
结构体在C 语言和C++语言中广泛应用，可以用来表示复杂的数据结构，如链表、树等。
结构体的定义通常包含以下部分：- 结构体名：表示这个结构体的名称。
- 成员列表：列出结构体中包含的各个成员变量及其类型。
例如，定义一个表示学生的结构体：```cstruct Student {char name[20];int age;float score;};```4.RPM 包与结构体的关系RPM 包的二进制结构与结构体在概念上有相似之处，它们都是将不同类型的数据组合在一起。
然而，RPM 包的二进制结构更多地涉及到软件包的管理和安装，而结构体在编程语言中用于表示复杂的数据结构。
rpm详解
1）RPM（Redhat Package Management）是由RedHat研发的，在Linux 系统下的系统包管理工具。
RPM包的产生目的：使包的安装和卸载过程更容易，他能够证实一个包是否已正确安装了，能简化包的建立过程，能从原始码建立整个包，他能用于不同的体系结构。
RPM系统已成为目前Linux系统下包管理工具事实上的标准，并且他也移植到非常多商业的unix系统之下。
RPM包组成：由包标签对他标识，包标签包含软件名，软件版本，包的发行版本几部分。
在包的内部还包含包的建立时间，包的内容描述，安装包的所有文件的大小，数字签名以证实包的完整性等信息。
RMP包还包含包内的文件信息，其中包括：每个文件的文件名，每个文件的权限，文件的属组和拥有者，每个文件的md5校验和，文件的内容等。
RPM包名的组成：rpm包的名字都包含一个后缀“arch.rpm”，arch 指的是体系结构，对于Intel平台的有i386、i586、i686等，你所安装的包必须要和机器上的共享库的版本相匹配。
如果你发现某个RPM包没有安装，你能自己安装。
所有时候，你都能（必须是root用户）安装RPM包。
RPM包管理系统提供的功能：安装新的包，卸载旧的包，将一个旧包升级为新的包，获得已安装包的信息等。
周详讲述RPM源码包的构成：RPM需要一系列目录完成建立的工作。
正常的目录结构通常由一个顶级目录/usr/src/redhat/和五个子目录构成。
这五个子目录分别是：SOURCES------包含原始的源文件和补丁文件。
SPECS--------包含控制RPM包建立过程的spec文件。
BUILD--------包含源码解包和软件建立的目录。
RPMS---------包含建立过程创建的二进制包文件。
SRPMS--------包含建立过程创建的源码包文件。
(在RPMS或SRPMS目录下通常还会有关于RPM包目标平台的目录。
例如，i386、i586、i686等代表和Intel兼容cpu的平台，noarch目录下的RPM 包代表能在所有平台下执行。
自动化利器-RPM自定义打包
⾃动化利器-RPM⾃定义打包1.Rpm打包程序1.1为什么要使⽤rpm打包1、编译安装软件，优点是可以定制化安装⽬录、按需开启功能等，缺点是需要查找并实验出适合的编译参数，诸如MySQL之类的软件编译耗时过长。
2、yum安装软件，优点是全⾃动化安装，不需要为依赖问题发愁了，缺点是⾃主性太差，软件的功能、存放位置都已经固定好了，不易变更。
===>如果你现在还为是使⽤编译安装软件还是使⽤yum安装软件发愁，那你就out了。
3、编译源码，根据⾃⼰的需求做成定制RPM包-->搭建内⽹yum仓库--yum安装。
结合前两者的优点，暂未发现什么缺点。
可能的缺点就是RPM包的通⽤性差，只能适⽤于本公司的环境。
另外⼀般⼈不会定制RPM包。
这是中⼤型互联⽹企业运维⾃动化的必要技能。
2 fpm⼯具打包详解FPM的作者是jordansisselFPM功能简单说就是将⼀种类型的包转换成另⼀种类型。
2.1 ⽀持的源类型包dir #将⽬录打包成所需要的类型，可以⽤于源码编译安装的软件包rpm #对rpm进⾏转换gem #对rubygem包进⾏转换python #将python模块打包成相应的类型2.2⽀持的⽬标类型包rpm #转换为rpm包deb #转换为deb包solaris #转换为solaris包puppet #转换为puppet模块2.3 fpm安装[root@student ~]# yum -y install ruby rubygems ruby-devel ß安装ruby模块[root@student ~]# gem install fpm ß安装fpm3.fpm常⽤参数-s #指定源类型-t #指定⽬标类型，即想要制作为什么包-n #指定包的名字-v #指定包的版本号-C #指定打包的相对路径 Change directory to here before searching forfiles-d #指定依赖于哪些包-f #第⼆次打包时⽬录下如果有同名安装包存在，则覆盖它-p #输出的安装包的⽬录，不想放在当前⽬录下就需要指定--post-install #软件包安装完成之后所要运⾏的脚本；同--after-install--pre-install #软件包安装完成之前所要运⾏的脚本；同--before-install--post-uninstall #软件包卸载完成之后所要运⾏的脚本；同--after-remove--pre-uninstall #软件包卸载完成之前所要运⾏的脚本；同--before-remove4.实战定制Nginx的Rpm包编写脚本[root@oldboy ~]# cd /server/scripts/ ß进⼊到/server/scripts[root@oldboy scripts]# vim nginx_rpm.sh ß这是安装完rpm包要执⾏的脚本#!/bin/bashuseradd nginx -M -s /sbin/nologinln -s /application/nginx-1.6.2/ /application/nginx[root@student scripts]# fpm -s dir -t rpm -n nginx -v 1.6.3 -d 'pcre-devel,openssl-devel' --post-install /server/scripts/nginx_rpm.sh -f /application/nginx-1.6.3/ ß打包no value for epoch is set, defaulting to nil {:level=>:warn}no value for epoch is set, defaulting to nil {:level=>:warn}Created package {:path=>"nginx-1.6.3-1.x86_64.rpm"}[root@student scripts]# rpm -qpl nginx-1.6.3-1.x86_64.rpm ß查看包内容[root@student scripts]# rpm -qp --scripts nginx-1.6.3-1.x86_64.rpm ß查看脚本postinstall scriptlet (using /bin/sh):#!/bin/shuseradd nginx -M -s /sbin/nologinln -s /application/nginx/nginx-1.6.3/ /application/nginx5.实战定制LNMP的Rpm包如果是rpm包直接依赖---然后替换配置⽂件，启动即可。
rpm包组成结构
rpm包组成结构RPM（Red Hat Package Manager）是一种在Linux系统中广泛使用的软件包管理工具。
它通过将软件打包成RPM包来方便地安装、升级和卸载软件。
RPM包的组成结构是指在创建和使用RPM包时所需的各个元素和组件。
本文将介绍RPM 包的组成结构，包括RPM包的文件结构、元数据和其他重要组件。
一、RPM包的文件结构RPM包的文件结构是指RPM包内部的目录和文件的组织结构。
RPM包内部有一些预定义的目录，包括：1. /usr：包含了系统的可执行文件、库文件和头文件等。
2. /etc：包含了系统的配置文件。
3. /var：包含了系统的变量文件，如日志文件和临时文件。
4. /bin：包含了系统的可执行文件。
此外，RPM包还包含了一些其他的目录和文件，包括：1. /usr/share/doc：包含了软件的文档文件。
2. /usr/share/man：包含了软件的man手册文件。
3. /usr/lib：包含了软件的库文件。
4. /usr/include：包含了软件的头文件。
RPM包的文件结构是由RPM包的构建过程和软件包的需求来确定的。
在创建RPM包时，需要将软件的文件和目录按照一定的规则放置到RPM包内部的相应位置。
二、RPM包的元数据RPM包的元数据是指RPM包中包含的关于软件的信息。
RPM包的元数据包括：1. 包的名称（Name）：指定了软件包的名称。
2. 包的版本（Version）：指定了软件包的版本号。
3. 包的发布（Release）：指定了软件包的发布号。
4. 包的摘要（Summary）：提供了软件包的简要描述。
5. 包的描述（Description）：提供了软件包的详细描述。
6. 包的依赖关系（Dependencies）：指定了软件包依赖的其他软件包。
7. 包的授权（License）：指定了软件包的授权信息。
8. 包的构建时间（Build Time）：指定了软件包的构建时间。
linux中的rpm命令的详细解释
linux中的rpm命令的详细解释linxu下的rpm命令其实是一个软件包管理程序。
下面由店铺为大家整理了linux的rpm命令的详细解释的相关知识，希望对大家有帮助!一、linux中的rm命令的详细解释1.什么是rpmRPM 是Red hat Package Manager 的缩写，本意是Red Hat软件包管理，由RedHat开发出来的一种软件包管理程序，后来被LSB(Linux规范标准)会正式吸纳为Linux的标准包格式，命名为RPM Package Manager,现在所说的RPM即使 RPM Package Manager的缩写。
2.为什么要使用RPM软件包管理器RPM软件包管理器简化了用户在Linux系统上对软件进行安装、卸载、升级或更新的过程，只需要简短的命令就可以完成，从而省去了对对源代码进行编译、安装的复杂过程，从而大大提高了管理人员的工作效率3.RPM命名格式命名格式：appname-VERSION-RELEASE.ARCH.rpmVERSION:magior：主版本号minor:次版本号release:发行号RELEASE：包自身的修订号，有时候会包含适用的OS信息:eg: bash-4.3.2-2.centos6.x86_64.rpm中 2.centos6 就是RELEASE号ARCH：适用平台x86: i386, i486, i586, i686x86_64: x86_64, amd64powerpc: ppcnoarch: 跟平台无关;(perl,python,ruby等编译的程序)RPM分包机制：核心包，主包：命名与源项目名称一致;eg: bash-4.3.2-2.centos6.x86_64.rpm子包(支包)：命令为源项目名称后附加支包中的文件提供的功能组成eg: bash-devel-4.3.2-2.centos6.x86_64.rpmRPM包获取途径1、系统的发行光盘镜像或官方站点2、程序包官方站点3、第三方组织：epel4、搜索RPM包的搜索引擎建议：生产过程中对rpm软件包安装之前需要验证程序包的来源合法性及包的完整性二、Linux中的rpm命令的安装方法安装语法格式：rpm {-i|--install} [install-options] PACKAGE_FILE1...安装时常用选项：-h: hash，以#来表示安装进度;每个# 号表示2%的安装进度-v, --verbose：显示安装过程中的详细信息;-vv: 能显示更加详细信息-vvv：--test：测试安装，不执行真正的安装过程，而仅报告依赖关系及冲突信息等;--nodeps ：忽略依赖关系安装，【能安装成功，但未必能成功运行;】--replacepkgs：覆盖安装--重新安装并覆盖原有的文件--force：强制安装--olepackage：降级到旧版本--relocate 指明安装位置--replacefiles 指明安装时替换某个文件--replacepkgs 指明安装时替换整个包安装时常用组合： -ivh --ivvh三、Linux中rpm命令的升级步骤升级语法格式：rpm {-U|--upgrade} [install-options] PACKAGE_FILE ...-U: 升级或安装rpm {-F|--freshen} [install-options] PACKAGE_FILE ...-F：升级【只进行升级】升级常用选项-v, --verbose：显示升级过程中的详细信息;-vv: 能显示更加详细信息-vvv：--test：测试升级安装，不执行真正的升级安装过程，而仅报告依赖关系及冲突信息等;--nodeps ：忽略依赖关系进行升级，--force：强制升级--olepackage：降级到旧版本升级时常用组合： -Uvh --Uvvh注意1：一定不要对内核执行升级;Linux允许多内核共存，所以，可以直接安装多个不同版本内核;注意2：如果程序包的配置文件安装后曾被修改，升级时，新版本的文件不会覆盖老版本的配置文件，而把新版本的配置文件重命名(加后缀.rpmnew)后保存;。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Rpm打包原理详解为什么要打包？制作rpm 不仅仅是打包，更可以解决菜单创建、打补丁、完成大量预配置、与其他软件包互动等操作。
使用源代码安装要求用户了解基本的编译过程、能够应付各种不能编译的意外、必须自己完成抽象的配置、甚至懂得软件开发，能够自己打补丁，……对非计算机专业的用户而言简直就是天方夜谭。
这是把软件开发的最后一步抛给了用户，作为发行版，这是极不负责任的！也是不现实的，除非用lfs，但那是一本菜谱，不是真正的发行版。
软件作者发布源代码是正确的，负责的作者一般都同时提供rpm 和deb 包以及它们的源代码包。
除非他们不会制作。
愿意使用什么，那是个人的自由，但对外就不能只想到自己。
GNU 精神是一种公益精神，没有奉献精神，在自由软件领域是要遭唾弃的！直接使用其他发行版的rpm 常常是不行的。
不知道大家看没看“恼人的依赖关系”这个帖子。
可以在技术支持区搜索一下。
任何两个发行版本在二进制上都是不能兼容的！他们实际是不同的操作系统。
不仅使用的库文件不同，配置也迥异。
特别是同一个发行版的不同版本更不兼容。
任何包都必须在本地重新编译，而且不一定通得过，因为还有spec 宏的兼容问题！如果要在别的发行版上使用，必须用源码编译，这是常识。
考虑文件布局和配置问题，有时直接编译也是不够的，必须修改spec，甚至自己打补丁。
如何创建rpm 包？rpm 建包原理其实不复杂。
写spec 相当于一种脚本编程，主要是在spec 里提供一些软件相关信息，以及安装、卸载前后要执行的脚本，然后展开压缩的源代码包，打上补丁，执行编译，然后利用make install 可以重新指定安装目的地的特性，把编译好的文件安装到指定的虚拟根目录下的指定位置里，一般是虚拟的/usr 里，然后把这些目录、信息和脚本打成一个压缩包，即rpm 包。
同时可选地生成源码包src.rpm。
当然有很多具体细节问题。
您应该首先阅读软件的readme 和INSTALL 文件。
打包原则1. 任何人都应该在系统现有src.rpm 的spec 基础上修改更新，除非没有这样的包。
这可以省去很多麻烦，少走弯路。
2. 任何人都无权删除别人的changelog 和原始打包者的信息，这是对别人的不尊重。
但你可以追加自己的信息。
3. 尽可能在spec 里使用系统的标准宏定义，而不要用非标准写法。
4. 任何人都不应该直接提供修改后的源代码，而应该以补丁形式发布你的修改，在spec 里完成打补丁操作。
务必做到一个补丁只解决一个问题，这样才能确保补丁的可重用性，否则版本升级后补丁很容易失效。
如果你确信自己的补丁是清洁补丁，尽可能发给上游开发者，这样才能一劳永逸。
你所打的任何补丁，其授权方式必须和被修改源代码保持一致。
预备知识：首先我们观察一下rpm 文件名的特点。
一个rpm 包文件名通常由 5 段组成：%{name}-%{version}-%{release}.ix86.rpmcutedict-1.1-1mgc.i686.rpm这里%{name}=cutedict，%{version}=1.1，%{release}=1mgc，ix86=i686，如果是为athlon 芯片家族编译的包，这里就是athlon，依此类推。
注意：下面是一个spec 模板。
1. 凡是行首加上# 的都被注释掉了，实际运行时不起作用，如要使其生效，请去掉注释符#。
2. 凡是以%{***} 和%*** 形式出现的符号都是“宏”，很多宏都是系统预定义的［注2］，也可以是自己定义的。
3. 下面的黑体字是spec 文件的关键字，不能写错。
4. 有不明白的地方可以参见跟帖里的参考文献。
5. 如果软件没有使用GNU autotool 创建，而是自己写的Makefile，这就导致不能按照常规方法打包，非常麻烦。
6. 服务器软件通常都需要大量预配置工作，spec 打包绝非一两天能解决，需要深入研究很多东西和反复实践，建议初学者不要尝试。
7. 其他发行版的spec 与src.rpm 是很好的教材，建议打包前先找找Fedora 或SuSE 的文件学习，能借鉴最好，但不应该不修改照搬过来或使用Mandrake 的文件，因为它使用的大量宏定义和我们不兼容，甚至src.rpm 直接编译都通不过。
------------------------------------------------------------------[spec 文件头部]# Initial spec file created by autospec #这里是一些注释%define _noautoreq perl(Plot) perl(WidgetDemo) #这里用%define 自定义一个系统里没有的叫做_noautoreq 的宏，后面可以用%{_noautoreq} 引用。
Name: software #这是软件包名称，后面可以用%{name} 引用Summary: a software #这是软件包的内容提要#Summary(zh_CN): #这里写入中文内容提要(如果有必要。
不建议使用，因为如果系统里的默认编码与此处不符，会导致显示乱码。
例如：我们使用GBK，如果这里的中文是UTF-8 编码，在kpackage 里就会显示乱码，但是synaptic 可能能够正确显示，但需要把zh_CN 改为zh_CN.UTF-8 )Version: number #这是软件的实际版本号，例如2.1.6、2.2final 等，后面可以用%{version} 引用Release: number #发布序列号，我们用1mgc、2mgc 等等，标明这是第几次打包。
如果软件本身是预览版，比如pre6 版，则写成pre6_1mgc、pre6_2mgc，后面可以用%{release} 引用Group: Applications/Multimedia #这是软件分组，建议使用标准分组，参见下面：［注1］#Group(zh_CN): #中文软件分组(如果有必要)License: GPL #这是软件版权证书，通常是GPLSource: %{name}-%{version}.tar.gz #这是源代码(通常是压缩包)，可以带有完整的网址，可以用正整数标识多个源Source0 Source4 Source5 Source100，数字不必连续排列，后面可以用%{SOURCE0}、%{SOURCE4}、%{SOURCE5}、%{SOURCE100} 引用。
例如/src/%{name}-%{version}.tar.gzBuildRoo t: %{_tmppath}/%{name}-%{version}-%{release}-buildroot #这是make install 时使用的“虚拟”根目录也称为“构建根”目录，通常是/var/tmp/软件名称-版本号-发布序列号-buildroot，make install 时一般会将软件安装在/var/tmp/软件名称-版本号-发布序列号-buildroot/usr/ 下的bin/ 下(可执行文件)、share/ 下(数据、资源文件)、lib/ 下(共享库文件)等等，例如/var/tmp/cce-0.51-1mgc-buildroot/usr/bin/cce。
不过实际不一定都是这样，具体情况具体对待# 下面是可选的字段URL: / #这是软件主页地址#Vendor: Red Hat Co.,ltd. #这是发行商或者打包组织的信息，我们统一写成MGC Group，不过这一行可以省略，把它写入/usr/lib/rpm/macros 标准宏定义文件里，该文件的Vendor 这行定义是空的，而且通常前面用# 注释掉了#Distribution: Red Hat Linux #这是软件针对的发行版标识，我们是Magic LinuxPatch: src-%{version}.patch #这是补丁源代码(可以是压缩包)，可以用正整数标识多个源Patch1 Patch4 Patch6，数字不必连续排列。
Prefix: %{_prefix} #指定make install 时在虚拟根目录里的安装位置，通常用标准的%{_prefix} 宏，它代表/usr。
这里指定后，用户可以在rpm 安装阶段重新指定安装到其他位置，如/opt，否则就不能改变安装位置。
Prefix: %{_sysconfdir} #如果软件有些文件并非都安装到%{_prefix}，那么你需要指明其他位置。
例如你需要把一个配置文件放到/etc 下面，这显然不在/usr 下面，此时你需要前方这种写法。
%{_sysconfdir} 宏代表/etc。
这里指定后，用户可以在rpm 安装阶段重新指定这些文件安装到其他位置，如/opt/etc，否则就不能改变安装位置。
［注3］#BuildArch: noarch#编译目标处理器架构，就是今后软件运行时的CPU 类型。
noarch 是不指定架构，通常标准默认是i386，定义在了系统的标准宏定义文件/usr/lib/rpm/macros 里［注2］。
实际编译时可以在rpmbuild 命令行用--target=i686 参数，spec 里通常不写这行。
#Requires: XFree86>=4.3 zlib libpng #这里罗列所有安装本包时需要先行安装的包(依赖包)，通常软件会依赖这些包里的一部分文件。
可以分成多行来写。
如果这里不写明依赖包，打包时系统会自动把具体依赖的.so 文件写进rpm 包，而不会注明这些文件属于哪些软件包，这会对用户造成困惑，因为他们很难知道这些文件属于哪些软件包#Obsoletes: #这里列出的软件包都是“陈旧”的，当安装本包的时候，这里列出的包都会被自动卸载！NoAutoReq: %{_noautoreq} #这里的意思是禁止自动查找对spec 文件头部预定义的_noautoreq 宏里定义的两个软件包[perl(Plot) 和perl(WidgetDemo)]的依赖关系，通常对于prel 模块需要这样处理。
因为即便你在Requires 字段指明了本包所依赖的包含这两个模块的那些软件包，安装本包的时候系统仍然会直接查找是否安装有这些perl 模块，而不会查找那些包含这两个模块的软件包是否已经安装。
#PreReq: loop #如果在%post 字段执行的脚本需要使用一些特殊命令，例如loop，你需要在此标明#Requires(post): loop #这是上面一行的另一种写法#Autoreq: 0 #这里使用0 关闭了自动标注本软件包需要的依赖关系的功能，使用1 或者不写此行(默认)就是开启自动标注依赖关系的功能。