下载文档原格式
rpm打包整理最近在学习之余，学习了rpm打包，整理了一些资料（基于Qomo平台）首先介绍下RPMRPM 是 Red Hat Package Manager 的缩写，原意是Red Hat 软件包管理。
这里先介绍一下RPM的一些用法。
查询功能：1、对系统中已经安装的软件查询：rpm -q softwarename2、查询系统中已安装的包：rpm -qa [softwarename]3、查询已安装软件包都安装到何处：rpm -ql softwarename安装，删除 rpm -ivh softwarename.rpm rpm -e softwarename其余更多的用法参照man rpm打包前的工作：1、安装打包套件：$sudo yum install rpm-build2、建立打包的环境：不建议用 root 来打包套件，所以请改用一般的使用者身分来打包套件,首先要安装 fedora-rpmdevtools 这个套件.接著执行 fedora-buildrpmtree 来建立打包的环境：$sudo yum install fedora-rpmdevtools 执行完后，就会在HOME目录下生成rpmbuild目录在 rpmbuild 目录底下又有 BUILD RPMS SOURCES SPECS SRPMS 五个子目录也可以自己手动创建这五个目录：mkdir -p ~/{BUILD,RPMS,S{OURCE,PEC,RPM}S}这些目录的作用如下BUILD 编译时所用的暂存目录RPMS 放置打包好的套件SOURCES 放置套件的原始码及修补档等等SPECS 放置 .spec 档 SRPMS 放置 Source RPMS (.src.rpm)3、这里为了提高书写spec文件的效率，介绍几个vim的插件spec文件里面有Group和%Changelog书写比较麻烦，将rpmgroups文件放在/usr/share/vim/vim72/plugin/下，然后执行source /usr/share/vim/vim72/plugin/rpmgroups.vim在/etc/vimrc文件最后加上：letpackager="<********************>"，“ ”中的是你的邮箱名。
RPM打包浅析RPM打包浅析0：需要储备的知识及其⽬的：需要要储备的知识对makefile有⼀定的了解。
C代码的编译及基本的C语法。
注：只需要能基本看懂第⼆节做好准备打包⼀个简单程序的内容即可。
教学⽬的能将⾃⼰编写的程序打包成RPM包，发布到⽹上供⼤家下载并安装使⽤。
⼀：RPM 基础知识若要构建⼀个标准的 RPM 包，您需要创建.spec⽂件，其中包含软件打包的全部信息。
然后，对此⽂件执⾏rpmbuild命令，经过这⼀步，系统会按照步骤⽣成最终的 RPM 包。
⼀般情况，您应该把源代码包，⽐如由开发者发布的以.tar.gz结尾的⽂件，放⼊~/rpmbuild/SOURCES⽬录。
将.spec⽂件放⼊~/rpmbuild/SPECS ⽬录，并命名为 "软件包名.spec" 。
当然，软件包名就是最终 RPM 包的名字。
为了创建⼆进制（Binary RPM）和源码软件包（SRPM），您需要将⽬录切换⾄~/rpmbuild/SPECS并执⾏：$ rpmbuild -ba NAME.spec当执⾏此命令时，rpmbuild会⾃动读取.spec⽂件并按照下表列出的步骤完成构建。
下表中，以%开头的语句为预定义宏，每个宏的作⽤如下：阶段读取的⽬录写⼊的⽬录具体动作%prep%_sourcedir%_builddir读取位于%_sourcedir⽬录的源代码和 patch 。
之后，解压源代码⾄%_builddir的⼦⽬录并应⽤所有 patch。
%build%_builddir%_builddir编译位于%_builddir构建⽬录下的⽂件。
通过执⾏类似 "./configure && make" 的命令实现。
%install%_builddir%_buildrootdir 读取位于%_builddir构建⽬录下的⽂件并将其安装⾄%_buildrootdir⽬录。
用Rpmbuild打包总结这些都是对这些软件简单的介绍，一些基本的信息！！Name: SipMonitorVersion: 1.0Release: 1%{?dist}Summary: for qt studyGroup: Development/ToolsLicense: GPLURL: /178926426Source0: %{name}-%{version}.tar.gzBuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root%descriptionThe GNU wget program downloads files from the Internet using the command-line.%prep //这个是编译之前预处理！一般就是解压，然后进入到解压文件夹下。
下面有一段文字对%prep与%setup的一些参数讲解很详细的文章%setup -q%build%install%{__rm} -rf %{buildroot}make#%makeinstallmake install%{__install} -d %{buildroot}%{_datadir}/SipMonitorcp -a ./* %{buildroot}%{_datadir}/SipMonitor%postcp %{_datadir}/SipMonitor/sip_monitor %{_bindir}ln -sf %{_datadir}/SipMonitor/sip_monitor /root/Desktop%postun%{__rm} -rf %{_bindir}/sip_monitor%{__rm} -rf /root/Desktop/sip_monitor%cleanrm -rf $RPM_BUILD_ROOT%files%{_datadir}/SipMonitor%changelog* Wed Sep 10 2008 Wangjun- Make the spec file,first%prep :此为预处理段,其内容为预处理脚本程序。
Rpm打包原理详解Rpm打包原理详解为什么要打包？制作rpm 不仅仅是打包，更可以解决菜单创建、打补钉、完成大量预配置、与其他软件包互动等操作。
使用源代码安装要求用户了解基本的编译过程、能够应付各种不能编译的意外、必须自己完成抽象的配置、甚至懂得软件开发，能够自己打补钉，……对非计算机专业的用户而言简直就是天方夜谭。
这是把软件开发的最后一步抛给了用户，作为发行版，这是极不负责任的！也是不现实的，除非用lfs，但那是一本菜谱，不是真正的发行版。
软件作者发布源代码是正确的，负责的作者一般都同时提供rpm 和deb 包以及它们的源代码包。
除非他们不会制作。
愿意使用什么，那是个人的自由，但对外就不能只想到自己。
GNU 精神是一种公益精神，没有奉献精神，在自由软件领域是要遭唾弃的！直接使用其他发行版的rpm 常常是不行的。
不知道大家看没看“恼人的依赖关系”这个帖子。
可以在技术支持区搜索一下。
任何两个发行版本在二进制上都是不能兼容的！他们实际是不同的操作系统。
不仅使用的库文件不同，配置也迥异。
特别是同一个发行版的不同版本更不兼容。
任何包都必须在本地重新编译，而且不一定通得过，因为还有spec 宏的兼容问题！如果要在别的发行版上使用，必须用源码编译，这是常识。
考虑文件布局和配置问题，有时直接编译也是不够的，必须修改spec，甚至自己打补丁。
如何创建rpm 包？rpm 建包原理其实不复杂。
写spec 相当于一种脚本编程，主要是在spec 里提供一些软件相关信息，以及安装、卸载前后要执行的脚本，然后展开压缩的源代码包，打上补丁，执行编译，然后利用make install 可以重新指定安装目的地的特性，把编译好的文件安装到指定的虚拟根目录下的指定位置里，一般是虚拟的/usr 里，然后把这些目录、信息和脚本打成一个压缩包，即rpm 包。
同时可选地生成源码包src.rpm。
当然有很多具体细节问题。
您应该首先阅读软件的readme 和INSTALL 文件。
⾃动化利器-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 编译原理-概述说明以及解释1.引言1.1 概述概述部分：RPM（Red Hat Package Manager）是一种用于管理和安装软件包的工具，在Linux系统中被广泛使用。
通过RPM，用户可以轻松地安装、升级、卸载软件包，使得软件管理更加便捷和高效。
RPM编译原理是指在安装软件包时，系统是如何根据软件包的源代码文件进行编译和打包的过程。
本文将详细介绍RPM的编译原理，包括RPM的定义和概念、编译原理的详细解释，以及编译的步骤和流程。
通过深入了解RPM编译原理，读者可以更好地理解软件包管理的原理和过程，为之后的软件安装和管理提供指导。
1.2 文章结构文章结构主要包括引言、正文和结论三部分。
1. 引言部分介绍了文章的概述，包括对RPM编译原理的初步介绍，文章结构的概览以及撰写本文的目的。
2. 正文部分主要分为三个小节:2.1 RPM的定义和概念，该部分主要介绍RPM的定义和相关概念，让读者对RPM有一个基本的认识和了解。
2.2 RPM编译原理详解，详细解释RPM编译原理的相关内容，包括核心概念、理论基础等，帮助读者深入理解RPM的编译原理。
2.3 RPM编译的步骤和流程，具体介绍RPM编译的步骤和流程，让读者掌握RPM编译的实际操作方法。
3. 结论部分包括三个小节:3.1 总结RPM编译原理的重要性，总结RPM编译原理在软件开发中的重要性，并提出相关建议和看法。
3.2 未来发展方向，探讨RPM编译原理的未来发展方向和趋势，展望RPM编译原理在未来的应用和发展。
3.3 结论，对全文内容进行总结，强调RPM编译原理的重要性和价值，为读者留下深刻印象。
1.3 目的本文的主要目的是深入探讨RPM 编译原理，帮助读者更好地理解RPM 软件包管理工具的工作原理。
通过对RPM 的定义和概念、编译原理的详细解释以及编译步骤和流程的分析，读者将能够更全面地了解RPM 软件包是如何被创建、编译和安装的。
此外，我们还将探讨RPM 编译原理的重要性，以及对未来发展方向的展望。
第五讲 RPM管理及文件打包和压缩一、 rpm 包1、rpm=redhat package managment红帽子担保理器，已成为整个linux行业的担保理的标准；2、linux下的软件安装方式<1>源代码安装<2>rpm包安装3、rpm 包安装的特色<1>长处：简单，方便，快捷<2>弊端：包的安装有依靠性4.rpm 包的安装：<1>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包的详尽信息<7>卸载已安装的 rpm 包#rpm -e已安装的RPM包名注意：不支持通配符卸载；<8> --force即便覆盖属于其余包的文件也逼迫安装--nodeps假如该RPM包的安装依靠其余包，即便其余包没装，也逼迫安装。
二、打包、查察、解包、压缩文件和目录命令:tar 1、对文件和目录的打包和压缩2、查察归档和压缩文件3、恢复归档文件和压缩文件三、压缩命令：gzip (gzip的压缩率高于bzip2)功能：用于压缩文件，不可以压目录，先把目录打包，再压缩。
选项：-c压缩结果写入标准输出，原文件保持不变。
rpm
RPM: 快速包管理器简介
引言
RPM (Red Hat Package Manager) 是一种流行的包管理系统，用于在基于RPM 的Linux 发行版中安装、更新、卸载和管理软件包。
RPM 的设计旨在提供快速和可靠的软件包管理，使用户能够轻松地安装和管理他们的软件资源。
本文将介绍 RPM 的基本概念、工作
原理以及在 Linux 系统中使用 RPM 进行软件包管理的常用命令。
1. RPM 的基本概念
1.1 RPM 软件包
RPM 软件包是一组预编译的二进制文件，通常包括软件的可执行文件、库文件、配置文件以及其他与软件相关的资源文件。
通过打包
这些文件，RPM 软件包可以被轻松地安装、卸载、更新和管理。
RPM 软件包还包含一些元数据，如软件包的名称、版本、作者等信息。
1.2 RPM 数据库
RPM 数据库是一个存储所有已安装和可用软件包的索引。
它类似于一个目录，帮助系统在需要时查找、管理和验证软件包。
RPM 数据库会记录已安装软件包的版本、文件位置等信息，方便后续的升级和管理操作。
2. RPM 的工作原理
RPM 的工作原理可以简单概括为以下几个步骤：
2.1 RPM 的安装
首先，需要在系统中安装 RPM 软件包管理器。
这可以通过基于RPM 的发行版的软件包管理工具来完成，如在 Red Hat 系统中使用 \。
RPM打包指南系列⼀RPM 打包指南简介这个指南包括以下三个部分如何准备⽤于 RPM 打包的源码包这是给没有软件开发背景的⼈准备的，参见如何把源码包打包进 RPM 包这适⽤于需要将源码包打包到 RPM 中的开发⼈员，参见⾼级打包技巧这是处理⾼级 RPM 打包⽅案的参考资料，参阅准备完成这个教程需要准备以下的包$ yum install gcc rpm-build rpm-devel rpmlint make python bash coreutils diffutils patch rpmdevtools为什么需要 RPM 来打包呢RPM 是运⾏在Redhat CentOS和Fedora上的包管理系统。
RPM 帮助你更简单的分发，管理和更新软件。
很多软件供应商通过传统的压缩包来分发软件。
但是，将软件打包到 RPM 中有⼏个优点，这些优点概述如下安装，重新安装，删除，升级和验证包⽤户可以使⽤标准的包管理⼯具（例如 Yum 或者 PackageKit）来安装，重新安装，移除升级和验证你的 RPM 包使⽤已安装软件包的数据库来查询和验证已安装软件包因为 RPM 维护已安装软件包及其⽂件的数据库，因此⽤户可以轻松查询和验证其系统上的软件包使⽤元数据来描述包，安装说明等每个 RPM 软件包都包含描述软件包组件，版本，发⾏版，⼤⼩，项⽬ url，安装说明等的元数据将原始软件打包为源包和⼆进制包RPM允许您获取原始软件源并将其打包为⽤户的源和⼆进制包。
在源包中，您拥有原始源以及所使⽤的任何修补程序以及完整的构建说明。
随着软件的新版本发布，此设计可以简化软件包的维护。
将包添加到 Yum 仓库你可以将软件包添加到 yum 仓库，是客户端可以轻松查找和部署软件对包进⾏数字签名使⽤ GPG 签名秘钥，你可以对包进⾏数字签名，以便⽤户能够验证包的真实性你的第⼀个 RPM 包创建⼀个 RPM 包可能是很复杂的。
这⾥有⼀个略过了⼀些步骤的完整的，简化的 RPM 的 spec ⽂件。
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 或者不写此行(默认)就是开启自动标注依赖关系的功能。
