RPM 使用和制作教程集合
时间:2003-07-29
来源:互联网
使用参考:
rpm -i --percent nmap-3.00-4.i386.rpm
用途:
将显示安装的百分比
-h or --hash
使用参考:
rpm -i --hash nmap-3.00-4.i386.rpm
用途:
在大文件安装比较友好,你可以不用怀疑是否机器出毛病了,可知道具体做到哪里.
-vv [for -i option]
使用参考:
rpm -i -vv nmap-3.00-4.i386.rpm
用途:
可以在安装的过程获得更多的信息
--excludedocs
使用参考:
rpm -i --excludedocs nmap-3.00-4.i386.rpm
用途:
将不安装DOC文档, 也就是说你在/usr/share/doc/目下下将没有 nmap-3.00的文档目录. 这在需要斤斤计较安装包所需要的空间比较有用,比如说你在做路由器?
--includedocs
使用参考:
rpm -i --includedocs nmap-3.00-4.i386.rpm
用途:
指定必需安装随包发送的文档
--replacepkgs
使用参考:
rpm -i --replacepkgs nmap-3.00-4.i386.rpm
用途:
即使该包已经安装了,还是强制再次安装一遍 .
--replacefiles
使用参考:
rpm -i --replacefiles nmap-3.00-4.i386.rpm
用途:
即使该包会覆盖一些别的包的文件,也继续安装
--force
使用参考:
rpm -i --force nmap-3.00-4.i386.rpm
用途:
忽略包和文件的冲突,强制安装
--noscripts
使用参考:
rpm -i --noscripts vsftpd
用途:
不执行vsftpd.spec 文件内的 %pre 和 % post脚本
例如: [%pre]
%prep
%setup -q -n %{name}-%{version}
%patch1 -p1 -b .rh
%patch2 -p1 -b .mok
cp %{SOURCE1} .
例如 : [%post]
%post
/sbin/chkconfig --add vsftpd
/usr/sbin/usermod -d /var/ftp ftp >/dev/null 2>&1 || :
--prefix <path>
使用参考:
rpm -i --prefix /tmp/local nmap-3.00-4.i386.rpm
用途:
使该包不安装到默认目录,而是安装到你指定的目录
--ftpproxy
使用参考:
rpm -i --ftpproxy <Proxy IP address> ftp://ftp.gnomovision.com/pub/rpms/f...1.0-1.i386.rpm
用途:
当你需要通过INTERNET 的FTP直接安装该包的时候,公司的局域网有限制,需要用FTP**才能访问FTP,那么就应该使用该参数
--ftpport <port>
使用参考:
rpm -i --ftpport <port> ftp://ftp.gnomovision.com/pub/rpms/f...1.0-1.i386.rpm
用途:
当你需要指定特定的端口号时需要使用
如何查询Red Hat 提供的包信息?
先安装一个RPM 包:
rpm -ivh rpmdb-redhat-version.i386.rpm
这个包是redhat的系统生产时附带的rpm包. 你可以通过这个数据包来查看某个特定的文件是由哪个包来提供的,这样可以解决一些包倚赖的问题.
举例说, 当你安装某个包时,出错,说缺少了libX11.so.6, 而你不知道哪个包提供这个文件的,那么可这样做:
rpm --redhatprovides libX11.so.6
--oldpackage
使用参考:
rpm -U --oldpackage packagename-oldversion.rpm
用途:
安装了一个包的更高版本,然后发现该版本有问题? 你更愿意回到低的版本? 没问题,可以"升级"到低的版本.
在RPM中查询更多的游泳信息? 那么应该充分挖掘更多的参数. IT's very powerfull!
--whatprovides
使用参考:
rpm -q --whatprovides /etc/httpd
用途:
查询系统中某个文件,某个目录,某个模块是由哪个包提供的.
--whatrequires
使用参考:
rpm -q --whatrequires module-info
用途:
查询系统中某个文件,某个目录,某个模块是哪个包需要的
-g
使用参考:
rpm -qg Base
用途:
查询属于某个组的包
-d
使用参考:
rpm -qdcf /sbin/dump
用途:
查询某个命令所属的包中相关联的所有已经被安装到系统的文档, 如果你碰到某个命令不知道是什么东西,想找它的参考文档,那么这个命令比较有用
--dump
使用参考:
rpm -ql --dump sendmail
用途:
想知道这个包安装完的所有情况? 包括所有的文件大小?目录位置?所有文件最后被修改的时间?所有文件的owner? group?....可以用这个参数.
--scripts
使用参考:
rpm -q --scripts XFree86
用途:
想看看RPM安装某个包前需要做什么? 安装完做什么? 用这个参数
某些特别的例子.关于查询
-qcf
使用参考:
rpm -qcf /bin/bash
用途:
用于获得某个包的配置文件及其具体位置
-qpil
使用参考:
rpm -qpil nmap-3.00-4.i386.rpm
用途:
查看某个未安装的RPM包的信息
作者: freebsdchina 发布时间: 2003-07-29
作者: boiyoo 发布时间: 2003-07-30
最初由 boiyoo 发表 支持! |
作者: shengjie 发布时间: 2003-08-13
rpmfind : rpm2html的客户端工具
1. rpmfind是什么?
2. 如何使用
1. 检索软件包
2. 安装软件包
3. 升级软件包
4. 最新软件包的检索
5. 限定到指定的发行套件
3. rpmfind的设置文件
4. 用rpmfind自动升级
5. 工作原理
6. 下载
7. 计划
在给作者发送bug报告邮件之前请先升级rpmfind到最新版,谢谢合作。
rpmfind是什么?
总得来说,rpmfind是一个为你在rufus上寻找RPM软件包的程序。
[译注]rufus是作者D. Veillard 提供的服务器。
举个例子, "rpmfind gimp" ,这个命令告诉你在电脑上安装Gimp需要哪些软件包,哪里可以找到它们,它们会占据多少硬盘空间(因此你也能计算出下载时间),同时为你取得那些软件包。
rpmfind也为电脑上现有的软件包提供查询RPM数据库服务,它支持关键词和正则表达式查询。
rpmfind能运行在一个特别的"upgrade"模式下,这样可以使电脑的上的各种软件包保持最新或者升级软件包到发行套间的新版本。关于此种模式下操作的具体信息,请参考autoupgrade。
如何使用:
Rpmfind有许多种不同的模式,这里只对标准模式下的操作做具体说明
搜寻软件包:
这种模式是根据关键字来检索相关的软件包。语法为"rpmfind --apropos regex" ,它会检索rpmfind.net上所有的软件包,这些软件包以名字和摘要说明为索引。
举个例子,我曾听说过一个类似Borland的编程工具,让我们去找它:
$ rpmfind --apropos borland
1: ftp://rpmfind.net/linux/contrib/i386...1.3-1.i386.rpm
rhide : Rhide is a very nice IDE exactly like Borland's
$
看来只检索到一个软件包,理论上所有名字和摘要说明包含关键字的软件包都会显示出来。
安装软件包:
这是rpmfind的“默认”模式,"rpmfind 软件包的名字",rpmfind会根据系统的发行套件为你锁定最合适的软件包,同时也列出其他相关用来处理依存关系的软件包。
举例,让我们在机器上来安装一个名为"xbill"的游戏:
$ rpmfind xbill
Arch : i586, Os : Linux
Default distribution : Red Hat Software(Hurricane)
owning 249 of 338 installed packages
Get http://rpmfind.net//linux/RDF/resources/xbill.rdf
Get http://rpmfind.net//linux/RDF/redhat...2.0-2.i386.rdf
Installing xbill will requires 183 KBytes
### To Transfer:
ftp://rpmfind.net/linux/redhat/redha...2.0-2.i386.rpm
Do you want to download these files to /tmp [Y/n/a] ? : y
saving to /tmp/xbill-2.0-2.i386.rpm
$
安装这个游戏只需要一个软件包,它被存在"/tmp"目录下。注意:rpmfind不需要root特权,任何用户都可运行。但是安装软件包无论如何是需要root特权的(执行"rpm -i /tmp/xbill-2.0-2.i386.rpm")。
升级软件包
在“默认”模式下,rpmfind不会尝试着替代现有的软件包,所以存在一个特别的“upgrade”模式用来更新陈旧的软件包。同时它也会检查依存关系并提出更新其它相关软件包的建议:
$ rpmfind -q --upgrade balsa
[search for approx 30 seconds ... 28.8 Kbps PPP connection]
Installing balsa will requires 9574 KBytes
### To Transfer:
ftp://rpmfind.net/linux/freshmeat/li...0.1-1.i386.rpm
ftp://rpmfind.net/linux/redhat/redha...9.1-1.i386.rpm
ftp://rpmfind.net/linux/redhat-labs/...3.0-2.i386.rpm
ftp://rpmfind.net/linux/contrib/hurr...3.0-4.i386.rpm
ftp://rpmfind.net/linux/redhat/redha....13-4.i386.rpm
ftp://rpmfind.net/linux/redhat-labs/...52414.i386.rpm
ftp://rpmfind.net/linux/redhat-labs/...52414.i386.rpm
ftp://rpmfind.net/linux/redhat-labs/...52414.i386.rpm
ftp://rpmfind.net/linux/redhat-labs/...52414.i386.rpm
ftp://rpmfind.net/linux/redhat-labs/...52416.i386.rpm
Do you want to download these files to /tmp [Y/n/a] ? : n
$
"-q" 标志用来减少rpmfind的冗余信息。
最新软件包的检索
rpmfind的最后一个模式是"latest",用来检索最新的软件包。这种模式下rpmfind不会给软件包所属发行套件或厂商优先权,它只会带回最新的软件包:
$ rpmfind -$ rpmfind -q --latest knews
Installing knews will require 668 KBytes
### To Transfer:
ftp://rpmfind.net/linux/redhat/redha....96-1.i386.rpm
ftp://rpmfind.net/linux/contrib/hurr...b.0-1.i386.rpm
Do you want to download these files to /tmp [Y/n/a] ? : y
Download libpng-0.96-1.i386.rpm [Y/n/a] ? :y
transfering ftp://rpmfind.net/linux/redhat/redha....96-1.i386.rpm
saving to /tmp/libpng-0.96-1.i386.rpm
Download knews-1.0b.0-1.i386.rpm [Y/n/a] ? :y
transfering ftp://rpmfind.net/linux/contrib/hurr...b.0-1.i386.rpm
saving to /tmp/knews-1.0b.0-1.i386.rpm
$
这个选项可能导致对“标准发布”的修改,因此可能致使在用户升级到更新的版本的时候出现问题。
限定到指定的发行套件
"--dist"选项可以使rpmfind按照所指定的发行套件取得相应的软件包:
$ rpmfind --dist redhat gpg
当然也可以在[package]部分使用no_distrib标志:
[packages]
no_distrib=rawhide
Rpmfind配置文件
rpmfind产生并维护一个个人配置文件,保存在"$HOME/.rpmfind"下。
这里有一些选项,它们所代表的意义和默认值是:
version
这由rpmfind维护,用来检查是否需要升级。
server
联系指定的RDF服务器,现在rufus是主用的服务器,bu的新镜像服务器也在运行中。
prefix
定义RPM本地数据库的存放位置,默认在"/usr/local"下,除非RPM不是系统自带的软件包格式。
downloadDir
定义下载软件包的存放位置,默认是"/tmp"。
httpProxy
你所使用HTTP**服务器的地址。
ftpProxy
你所使用FTP**服务器的地址
verbose
设置冗余度,默认是1,0比较安静,1 有点烦人哦:-)
mode
默认模式是检索,如果你喜欢冒险的话,也可以通过命令行选择"upgrade"和"lates"模式。
配置文件里列出了所有的选项,并作了简单的说明。
用rpmfind来自动升级
我建议选用最新的版本(至少要用1.5或其以上的版本)。
1. 选择自动升级的来源,就是ftp的地址或者别的什么地址。
2. 编辑你的".rpmfind"文件,每一个来源添加一个autoupgradeURL, 像这样:
autoupgradeURL=ftp://rpmfind.net/linux/redhat/updates/6.2/i386
autoupgradeURL=ftp://myserver.org/pub/rpm-updates/i386/
3. 运行 "rpmfind --autoupgrade"
4. 如果觉得满意就可以添加到root的crontab中去。
如果使用crontab,推荐做以下几件事:开启"paranoid"选项,在系统中配置gpg并且将发行套件密钥添加到root的gpg钥匙环中("gpg --import key")。
工作原理
rpm2html能输出软件包的相关信息,这些信息以RDF格式存储在rpmfind.net上。因而所有软件包的说明及其相关信息都输出在这些小RDF文件中。
当用rpmfind查找软件包时,rpmfind首先会查询本地的RPM数据库。当本地没有时,它才会向rufus上发送查询相关RDF文件的请求。文件内容经过分析从软件包提供的信息(厂商、版本、日期、等等.....)中提取到摘要说明。基于此,rpmfind根据适宜程度排列符合条件的软件包。随之,提取排列在第一位的软件包及其所有信息包括依存关系(dependency)等。基于上面的信息,rpmfind通过从网上抓取软件包来证实此软件包所需要的依存关系及其相关的资源都可提供。
最后,rpmfind列出软件包的清单和所需要的营盘空间。
如果rpmfind发现软件包中的一个所需要的资源不能提供,或者需要对libc进行升级,它就会放弃这个软件包进而选择下一个。
下载
最新版位于ftp://rpmfind.net/pub/rpmfind,它也是RedHat like distributions的一部分。
计划
许多事情要做的:
* 一个用户界面,用户可根据程序所提供的清单对其中的一些软件包再次进行选择。
* 根据RPM的版本,发行和序列号来选择软件包及其依存关系,但这需要对rpm2html程序和RDF文件的功能进行扩充。(部分已完成)
* 一个可选的图形界面。 (查看 gnorpm).
想现在使用rpmfind吗?下载!
作者: MerkavaIV 发布时间: 2004-01-15
作者: bbbush 发布时间: 2005-04-19
作者: fudaming 发布时间: 2005-04-19
这是个好东西,一定程度上自动解决依赖,会找当前目录下的所有rpm包,看能不能解决依赖的。
作者: fudaming 发布时间: 2005-04-19
我想知道 %setup 所有参数的含义, 可是还是没有找到
我想知道 %trigger 所有命令的用法,也还没有找到
预定义的变量列表到哪里去找?$RPM_BUILD_ROOT 和 %{buildroot} 都是在哪里定义的?
没头没脑搜索到一大堆, 不知道会不会有用. 好文档太少了
---
http://www.linuxsir.org/bbs/showthread.php?t=167093
http://www.linuxsir.org/bbs/showthread.php?t=160180
apeter_2000 用Checkinstall制作你自己的RPM, 包括对 checkinstall 打补丁使之适于 fedora |
lipeng21cn 我有一个linux的问题请各位前辈,我有些客户使用linux,有些软件我以前一直是用tar包的方式把软件给他。但是有些人搞不明白怎么装,尤其是路径的问题(由于我把tar包路径都做在了一起,并设置好了权限,需要cp到根目录解压才能拷贝到相应的目录)。我觉得这样很麻烦。看到网上很多关于rpm制作的文档,我觉得如果有这种方式很方便。但是那个spec怎么写呀,因为需要做成rpm包的都是一些配置文件或者二进制程序。没有源代码,但网上的文档都是介绍一些把源代码编译后做成rpm的。所以我有些糊涂,请前辈们指点 %config或者%doc默认最多只允许34个文件,如果多了在rpmbuild -bb -vv的时候报错。 在spec中加入%define __check_files %{nil}即可解决此问题 |
home_king
rpm2cpio 的源代码 perl rpm2cpio filename.src.rpm > filename.tmp && cpio -d -i < ./filename.tmp |
greenforce
RPM Builder plugin for Anjuta This is a dynamic library plugin for Anjuta v1.1.1. http://arpmbuilder.sourceforge.net/ |
greenforce 使用checkinstall制作的rpm包能否在rh中使用? 他的主页。和软件文档。都标的很清楚。 可惜软件只是制作RPM 无法写出spec |
me
tetex-fonts-zh 的 rpm spec 文件制作 |
ttyrone
rpmbuild 安装openpkg的问题, spec 出错 |
sherman
fedora core 3 的 release-notes 有关安装内核源码 |
beyond_2000
rpmbuild --rebuild kernel-xxx.src.rpm rpmbuild --rebuild --target=CPU-VENDOR-OS *.src.rpm 或者按照你上面的方法,安装后,到/usr/src/redhat/SPEC下 rpmbuild -bs --target=i686 kernel.spec 2个小时候后,你就可以在/usr/src/redhat/RPMS/i686下面找到几个编译好的内核文件。 |
jin.liu
这是一个偏向于 fedora 的,喜欢自己编译,并且可以自行编译 qt 的家伙, 会修改 spec
$RPM_OPT_FLAGS 是在什么地方定义的? |
chemist
如何避免生成 debuginfo? %define debug_package %{nil} |
哈蜜瓜的 simsun 的 rpm 的 spec 文件 |
http://www.linuxsir.org/bbs/showthread.php?t=47028
哪里能找到gnome 2.3.1各tarball的spec文件 winix Winix Is Not In Xanadu. http://people.ecsc.co.uk/~matt/downl...redhat-9-i386/ |
greenforce
如果为了管理软件。方便。 可以用 checkinstall 软件。制作RPM包。 http://asic-linux.com.mx/~izto/check...l/download.php 通常。 ./configure , make , makeinstall 用checkinstall通常是 ./configure , make , checkinstall –R make install. 就ok了。。。 同时会生成 spec 和 rpm 文件 |
freebsdchina
一些 rpm 命令的选项含义 但是没有翻译完整的 man rpm |
dato
mplayer 1.0pre3 SPEC 根据 turbolinux 的文档和 spec 修改而成 |
http://www.linuxsir.org/bbs/showthread.php?t=42932
linux 软件专题讨论版
哈蜜瓜
RPM SPEC文件编写通用规范 参考了 RedHatLinux .spec file Specification and RPM HOWTO and Maximum RPM |
http://www.linuxfans.org/nuke/module...wtopic&t=86942
lovewilliam
http://www.magiclinux.org/people/lovewilliam
autospec, 写spec打包时用的小工具 http://www.npsnet.com/danf/software/ 我对其中的一些文件做了修改 自己试一下就知道了 RPM: http://www.magiclinux.org/people/lov...mgc.noarch.rpm SRPM: http://www.magiclinux.org/people/lov...8-3mgc.src.rpm |
KDE
对某个 spec 的错误的手把手修改 |
KDE
Magic Linux开发培训版 rpm 建包原理(20050405 更新) |
KDE
%setup -n %{name} 的含义 |
aniuge007
内核的 spec |
myleader
xmame 的 spec |
http://download.enet.com.cn/html/262392001011002.html
rpmbuilder 的下载地址
Clear River Technologies
http://www.klabs.net/rpmbuilder/
RPM Builder 能够将tar.gz 格式的文件转换为RPM 格式的包。它可以自动的产生所必需的RPM 格式文件摸板,然后创建RPM 格式文件和SRPM 格式文件。即使你不了解RPM 包,你也可以使用这个软件创建一个RPM 包。 |
dato
一段很有道理的 shell 脚本
代码:
install -d $RPM_BUILD_ROOT%{_datadir}/mplayer/Skin/ ( cd $RPM_BUILD_ROOT%{_datadir}/mplayer/Skin/ tar Ixf %{SOURCE2} chmod -Rf a+rX,g-w,o-w . rm -rf `find -type d -name CVS` ) |
http://www.linuxsir.org/bbs/showthread.php?t=12586
http://www.linuxsir.org/bbs/showthread.php?t=1223
http://www.cngnu.org/technology/c496/307.html
都是转载的最初发表在赛迪网的帖子<精通 RPM> http://www0.ccidnet.com/tech/guide/ http://www0.ccidnet.com/html//tech/g...5/92_3852.html http://www0.ccidnet.com/html//tech/g...7/92_3873.html http://www0.ccidnet.com/html//tech/g...0/92_3875.html http://www0.ccidnet.com/html//tech/g...4/92_3850.html http://www0.ccidnet.com/html//tech/g...3/92_3844.html http://www0.ccidnet.com/html//tech/g...6/92_3893.html http://www0.ccidnet.com/html//tech/g...7/92_3894.html http://www0.ccidnet.com/tech/guide/2...8/58_3808.html http://www0.ccidnet.com/tech/guide/2...7/58_3797.html 制作篇, 校验篇, 查询篇, 签名篇, 杂项篇, 安装篇, 认识篇 |
http://www.linuxsir.org/bbs/showthread.php?t=28014
http://www.linuxsir.org/bbs/showthread.php?t=21993
probing
都是从红帽认证学习资料第四章摘录的 4.04 Using the Red Hat Package Manager Validating a Package Signature. 86 To Add and Remove Components. 94 NOTE: Be very careful about which packages you remove from your system. Like most Linux utilities, RPM assumes omniscience, and will silently let you shoot yourself in the foot. Removing the passwd or kernel package would be devastating. 113 Adding Updates, Security Fixes, and Other Items. 114 Verifying One or More Packages. 127 Seeing What Packages Are Installed. 139 Creating and Using Custom RPMs. 157 Building Custom Source and Binary RPMs. 175 Building an RPM from a Tar Archive. 181 |
http://book.jqinfo.com/product/314587.html
Linux技术参考手册——系统、综合篇
原价: ¥42.00元 出版社: 中国铁道出版社 作者: 赖阿福 高健智 ISBM: 7-113-03615-5 版次: 1 开本: 1/16 页数: 403 出版日期: 2000-01-01 本书是以原文版LDP(The linux DocumentationProject)的HOWTOS及HOWTO文件为主,经由CLDP(Cninese linux documentation project )组织将DP 文件逐步翻译成中文,再经赖阿福及高健知两位老师精选常用的技术文件整理成册,分成系统、综合篇及外设网络篇两册,希望对有心学习Linux的使用者有所助益。 19-6-2 The SpecFile 19- 6-3 The Header 19-6- 4Prep 19-6-5 Build 19-6-6Install 19-6-7 optional pre and post Install/Unlnstall Scripts 19-6-8 Files 19-6-9 Building It 19-6-10 Testing It。 19-6-11 What to do with your new RPMs? 19-6-12 What Now? 19- 7Multi-architectural RPM Building 19-7-1Smple Spec File 19-7 -2 optflags 19-7-3Macros 19-7-4 Excluding Architectures from Packages 19-7-5 Finishing Up 19-8 Copyright Notice |
http://www.smsd.com.cn/book.asp?Id=12776
深入LINUX建构与管理
作 者:杨文志 / 出版社:人民邮电出版社 日 期:2000年12月 开 本:787*1092 版 次:1次 页 数:711页 6.8 动手制作RPM套件 RPM spec文件编辑与介绍 自动产生RPM spec文件的工具 RPM package制作例子 RPM高级包装技巧 |
http://pkgcvs.turbolinux.co.jp/spec/spec-rule-cn.html
TurboLinux RPM SPEC文件编写通用规范 |
RPM 与 Tarball 套件管理员
这是一篇很老的帖子, 收藏只为完整性 |
自由软件发布方法惯例 |
http://www.linuxsir.org/bbs/showthread.php?t=172030
摘要:Checkinstall 是一个能从 tar.gz类的源代码自动生成RPM/Debian或Slackware安装包的程序。这样使你能用几乎所有的 tar.gz 类的源代码生成“干净”的安装或者卸载包。 |
http://www.rpm.org/RPM-HOWTO/
http://ichi.turbolinux.com/devel/doc...rbo/index.html TurboLinux RPM Packaging HOWTO
http://www.redhat.com/docs/books/max-rpm/max-rpm-html/
http://pkgcvs.turbolinux.co.jp/spec/maximum-rpm.ps Maximum RPM
http://www.redhat.com/docs/manuals/l...rpm-using.html
Red Hat Linux 9: Red Hat Linux Customization Guide Prev Chapter 32. Package Management with RPM |
在 Red Hat Linux 7.1 上使用 RPM |
CLDP -- Linux 中文文件计划 |
# Supported formats: 7z, ZIP, CAB, RAR, ARJ, GZIP, BZIP2, Z, TAR, CPIO, RPM and DEB |
RPM 與 SRPM 套件管理員
作者:VBird 感谢作者VBird同意本站转载这么精彩的文章。 |
作者: bbbush 发布时间: 2005-04-19
当前页面位置:主页:技术天地:编程指南:技术文章
制作篇(上)
(雨亦奇 赵建利 2001年12月05日 14:24)
要想制作一个RPM格式的软件包,需要编写软件包描述文件。其标准命名格式为:软件名-版本号-释出号.spec,这个文件,详细描述了有关该软件包的诸多信息,如软件名,版本,类别,说明摘要,创建时要执行什么指令,安装时要执行什么操作,以及软件包所要包含的文件等等。有了这个文件,RPM就可以制作出相应的包裹文件来。 下面以我制作小赵编辑器LZE的软件包(lze-6.0-2.i386.rpm)为例,详细说明一下软件包描述文件的书写。其描述文件为lze-6.0-2.spec,该文件内容如下:(用nl -ba命令列出,每行开头的数字为所在行在文件中的行号) 1 # 文件名称: lze-6.0-2.spec 2 # 文件功能: lze软件包描述信息 3 # 文件作者: 纵横软件制作中心雨亦奇 国防大学研究生二队赵建利 4 # 修改时间: 2001.10.19 5 6 Name: lze 7 Version: 6.0 8 Release: 2 9 Summary: 小赵全屏幕中英文多窗口多功能编辑器(LINUX/UNIX系统适用) 10 Group: Applications/Editors 11 License: Share 12 Vendor: 纵横软件制作中心 13 Packager: 雨亦奇([email protected]) 14 Source: http://zhsoft.myetang.com/lze-6.0-2.src.tgz 15 Prefix: /usr 16 Requires: /bin/sh 17 Provides: lze-edit 18 19 %description 20 小赵编辑器,是为使用SCO UNIX,LINUX多用户系统的广大用户专门设计的全屏幕多窗 21 口中英文多功能编辑器。 22 它主要有以下十大特点:1.全屏幕菜单操作。2.显示方式多样。3.块操作丰富。4.十 23 字制表功能强大。5.多窗口操作灵活自如。6.文件操作功能齐全。7.解释输出功能独具特 24 色。8.自带中文输入法(增强五笔和增强拼音),实用方便。9.十六进制编辑功能,如虎 25 添翼。10.即时翻译,按到即译。 26 总之,小赵编辑器会成为您在UNIX,LINUX系统上编制程序和书写一般性文稿的好帮手。 27 它将在工作中助您一臂之力,轻松上阵,游刃有余! 28 29 %prep 30 echo "预处理脚本程序(prep)开始执行" 31 %setup 32 33 %build 34 echo "编译连接脚本程序(build)开始执行" 35 make 36 37 %install 38 echo "安装脚本程序(install)开始执行" 39 make install 40 41 %clean 42 echo "建包结束后清理脚本程序(clean)开始执行" 43 44 %pre 45 echo "安装前执行脚本程序(pre)开始执行" 46 47 %post 48 echo "安装后执行脚本程序(post)开始执行" 49 50 %preun 51 echo "卸载前执行脚本程序(preun)开始执行" 52 53 %postun 54 echo "卸载后执行脚本程序(postun)开始执行" 55 56 %veryfiscript 57 echo "软件包校验脚本程序(verifyscript)开始执行" 58 59 %triggerin -- xiuwu 60 echo "软件包安装时触发脚本程序(triggerin)开始执行" 61 62 %triggerun -- yuntaishan < 2.0 63 echo "软件包卸载前触发脚本程序(triggerun)开始执行" 64 65 %triggerpostun -- dapubu 66 echo "软件包卸载后触发脚本程序(triggerpostun)开始执行" 67 68 %files 69 %defattr (-,root,root) 70 %config /etc/funkey.def 71 %config /etc/inputme.def 72 %doc /usr/doc/lze-6.0/README 73 %doc /usr/doc/lze-6.0/LICENSE 74 /usr/bin/lze 75 /usr/bin/lzeime.py 76 /usr/bin/lzeime.wb 77 /etc/wbzc.dat 78 79 %changelog 80 * Tue Aug 18 1998 雨亦奇 <[email protected]> 81 - 内置拼音,五笔输入法 82 * Fri May 01 1998 雨亦奇 <[email protected]> 83 - 增加多窗口操作 84 * Mon Mar 24 1997 雨亦奇 <[email protected]> 85 - 增加块操作命令 86 该描述文件包括以下几方面的内容: 一、注释行 见第1-4行。 它以#号开头,起注解作用,可帮助用户理解所写的内容,但对软件包的生成不起任何作用。此文件中,注释行集中在文件首部。实际上,它可位于描述文件的任何位置。 二、文件头 见第6-17行。 文件头描述软件包的基本信息,它包含若干个域,其中有必选的域,也有可选的域。一个域占用一行,其描述格式为: 域名 : 域值 注意: 域名不分大小写,并且域值不能为空。 文件头必选域有以下六个: 1. Name : 此域定义软件名。 2. Version : 此域定义版本号。仅当软件较以前有较大改变时才增加版本号。注: 版本号中不能含减号(-)字符。 3. Release : 此域定义释出号。若软件较以前改变较小,则仅增加释出号,不改变版本号。注: 释出号中亦不能含减号(-)字符。 RPM利用上述的Name(软件名),Version(版本号),Release(释出号)及体系号来命名软件包,如本例输出的包裹文件名为lze-6.0-2.i386.rpm。 4. Summary : 此域定义软件包简介,为一句话说明。 5. Group : 此域定义软件所属类别,详见<<精通RPM之五--查询篇>>,本例的Applications/Editors表示本软件属"应用/编辑器"类。 6. License : 此域定义软件适用的许可证或版权规则。该域也可用Copyright(版权)来定义,二者同意。许可证具体有: GPL(通用公共许可证,自由软件适用),BSD,MIT,Public Domain(公共域),Distributable(贡献),Commercial(商业),Share(共享)等。 文件头可选的域包括如下几类: 1. 基本信息 1.1 Vendor : 此域定义软件的供应商(销售商)。 1.2 Distribution : 此域定义软件所属的发行版,这是软件包制作者自己的分类。通常,一个发行版由若干个软件包构成。如我想做一个名为“熊猫'95”的发行版,则其中每个软件包(如竹叶95)的描述文件都应有这么一行: Distribution : 熊猫'95 1.3 Icon : 此域指定软件包所用的图标文件名。此文件为GIF或XPM格式,必须存放在RPM的%_sourcedir(源码目录)宏所指示目录下,默认为 /usr/src/dist/SOURCES。RPM本身并不使用图标,但它将图标文件内容存贮到包裹文件中,安装时亦存贮到RPM数据库中。此图标可被图形界面的RPM包管理工具使用,用以改善界面效果,增加可视性。如下例指示软件包使用panda.xpm作为图标: Icon : panda.xpm 1.4 Packager : 此域定义打包者,亦即建立此软件包的人或公司。书写格式是: 打包者的名字 <电子信箱或相关网页> 请参考描述文件第13行。 1.5 Serial : 此域定义软件序列号,也可使用域名Epoch。软件序列号为一整数,由打包者指定,它应随着版本号的增加而不断增加,并且始终保持数值的唯一。软件序列号可被用来说明软件包之间的依赖关系。下例指定软件包序列号为4: Serial : 4 或用: Epoch : 4 1.6 URL : 此域定义包含打包软件有关信息的网页地址。如: URL : http://devplanet.fastethernet.net/gxedit.html 2. 依赖相关 依赖是RPM用来描述软件包之间关系的。一个软件包依赖的东西RPM称作功能,它可以是真实存在的软件包,也可以是虚拟的软件包(虚包)。虚包没有版本号。 依赖相关的域有: 2.1 Provides : 此域定义软件包提供的功能,可重复多行。其描述格式为: Provides : 功能1 [,功能2] ... 注: []所括为可选项,多个功能之间以逗号或空格分隔。 软件包所提供的功能一般是以虚包形式存在的共享库。当有多个软件包均提供相同的服务时,常用虚包来表示其服务。如,一个邮件客户端软件允许用户使用不同的看信方式(文本形式,HTML形式等),可以要求任何一个看信程序必须提供mail-reader虚包。这样,看信程序的描述文件应有这么一行: Provides : mail-reader 如此它才能被邮件客户端使用。 2.2 Requires : 此域定义软件包所需的功能,可重复多行。其描述格式为: Requires : 功能1 [比较符1 [序列号1:]版本号1[-释出号1]] [,功能2 [比较符2 [序列号2:]版本号2[-释出号2]]] ... 其中: * []所括为可选项; * 比较符可使用<(小于),>(大于),=(等于),>=(大于等于)或<=(小于等于); * 序列号不选时,RPM默认为0; * 功能之间的逗号可选,也可使用空格进行分隔。 例子:Requires: aaa, bbb >= 3.0, ccc < 2:5.0-1 注: 本例定义生成的包在安装时需要系统有如下功能: (1) aaa(系统中已安装aaa包,或者已安装软件包中有软件包提供aaa虚包); (2) bbb包已安装且版本要求大于等于3.0; (3) ccc包已安装且版本要求小于序列号为2,版本号为5.0且释出号为1。 RPM在进行版本比较时,执行比较的顺序是; 先版本号,再释出号,最后比较序列号。通过比较,确定哪个版本较新,哪个版本较老。 2.3 Conflicts : 此域定义有哪些功能与本软件包相冲突(不能共存)。此域亦可在描述文件中书写多次。其描述格式形同Requires域,为: Conflicts : 功能1 [比较符1 [序列号1:]版本号1[-释出号1]] [,功能2 [比较符2 [序列号2:]版本号2[-释出号2]]] ... 其中: * []所括为可选项; * 比较符可使用<(小于),>(大于),=(等于),>=(大于等于)或<=(小于等于); * 序列号不选时,RPM默认为0; * 功能之间的逗号可选,也可使用空格进行分隔。 举个例子: Conflicts : xxx=1:2.0 yyy>=3.0 注: 本例阐明生成的包冲突的功能有: (1) 当系统中xxx包版本等于序列号为1且版本号为2.0时;(2) 当系统中yyy包版本大于等于3.0时。 *** 依赖关系的自动实现 *** 一般情况下,当RPM建立一个软件包时,它要执行/usr/lib/rpm目录下的两个小程序。一个是find-requires,用于查找软件包所需的共享库,这些库将以虚包的形式加入到该软件包所需的功能(Requires)之中。另一个是find-provides,它用于查找软件包所提供的共享库,这些库将以虚包的形式加入到该软件包所提供的功能(Provides)之中。这两个程序都是SHELL程序,代码量虽小,但确实帮了软件包制作者一个大忙--不必劳心费神地自己写这样的依赖关系了,因为程序均自动完成了。 下面三个域用于指示RPM是否执行这两个程序。 2.4 Autoreq : 此域用于指示RPM是否自动查找软件所需的共享库。仅当域值为no或0时,RPM不执行find-requires程序,否则均执行该程序。 2.5 Autoprov : 此域用于指示RPM是否自动查找软件提供的共享库。仅当域值为no或0时,RPM不执行find-provides程序,否则均执行该程序。 2.6 Autoreqprov : 此域用于指示RPM是否自动查找软件所需的共享库与其提供的共享库。仅当域值为no 或0时,RPM不执行find-requires与find-provides两个程序。此域相当于同时设定Autoreq 与Autoprov域值为指定之值。 注: 上述三个域在描述文件中,它们之间因为顺序的不同而结果会有所不同,一般以最后一个为准。如: Autoreq : yes Autoreqprov : no Autoprov : yes 注: 本例虽然第一行允许执行find-requires,但第二行又不允许find-requires与find-provides两个程序运行,而第三行允许find-provides运行,所以依照执行顺序,结果为不允许执行find-requires,而允许执行find-provides。 又如: Autoreq : no Autoreqprov : yes Autoprov : no 注: 本例的结果为允许执行find-requires,而不允许执行find-provides。 3. 系统相关 RPM制作软件包时,可以为其指定适用的CPU体系或操作系统,也可为其指定不适用的CPU体系或操作系统,这样,当RPM发现当前的CPU体系或操作系统与软件包要求的不兼容时,将中止软件包的制作。RPM默认的当前CPU体系由宏%_arch定义,一般为i386。RPM默认的当前操作系统由宏% _os定义,一般为linux。读者可以通过查看/usr/lib/rpm/macros宏定义文件得到。 下面四个域说明软件包的适用范围: 3.1 Excludearch : 此域定义软件包不适用的体系。RPM可选的体系名请参见/usr/lib/rpm/rpmrc文件中的arch_canon项目。 软件包不适用于某个体系,可能有两方面的原因。一是该软件还没有移植到所定义的体系上;二是该软件含有特定的机器码(汇编语言),它与别的体系不兼容。 此域描述格式为: Excludearch : 体系1 [体系2] ... 注: []所括为可选项,各体系之间以空格分隔。 如果当前体系在此域值之中,则RPM制作软件包时将报错退出,请看下面的例子。 在lze-6.0-2.spec文件头部分加入一行: Excludearch : i386 再运行建包命令rpm -bb(<<精通RPM之七--制作篇(下)>>将讲到): # rpm -bb lze-6.0-2.spec Architecture is excluded: i386 # 由上看出,RPM提示了“体系不适用: i386”的错误。 3.2 Exclusivearch : 此域定义软件包适用的体系。其描述格式与Excludearch类似: Exclusivearch : 体系1 [体系2] ... 注: []所括为可选项,各体系之间以空格分隔。 假如在lze-6.0-2.spec文件头加入一行: Exclusivearch : i386 sparc 再运行建包命令将会怎么样: # rpm -bb lze-6.0-2.spec Executing: %prep 预处理脚本程序(prep)开始执行 Executing: %build 编译连接脚本程序(build)开始执行 Executing: %install 安装脚本程序(install)开始执行 Processing files: lze Finding Provides: (using /usr/lib/rpm/find-provides)... Finding Requires: (using /usr/lib/rpm/find-requires)... Provides: lze-edit PreReq: /bin/sh Requires: /bin/sh ld-linux.so.2 libc.so.6 libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1) Wrote: /usr/src/dist/RPMS/i386/lze-6.0-2.i386.rpm # 看,此次建包(lze-6.0-2.i386.rpm)成功了,因为当前的体系(i386)正好适用。 3.3 Excludeos : 此域定义软件包不适用的操作系统。RPM可选的操作系统请参考文件/usr/lib/rpm/rpmrc中的os_canon项目。 其描述格式为: Excludeos : 操作系统1 [操作系统2] ... 注: []为可选项,操作系统之间以空格分隔。例如: Excludeos : irix aix solaris 注: 如将此行加入到lze的描述文件中,则它会指示RPM不在irix,aix,solaris这三个操作系统上建立lze软件包。如果当前操作系统是三者之一,则RPM会报错并中止软件包的制作。 如: # rpm -bb lze-6.0-2.spec OS is excluded: Solaris # 3.4 Exclusiveos : 此域定义软件包适用的操作系统。其描述格式为: Exclusiveos : 操作系统1 [操作系统2] ... 注: []为可选项,操作系统之间以空格分隔。例如: Exclusiveos : linux solaris 4. 目录相关 4.1 Prefix : 此域定义可重定位的目录前缀,可在描述文件中书写多次。其描述格式为: Prefix : 目录前缀1 [目录前缀2] ... 注: []为可选项,各目录前缀之间均以空格分隔。例如: Prefix : /usr /etc 它也可写作: Prefix : /usr Prefix : /etc RPM利用可重定位的目录前缀,实现了软件包的重定位安装,使软件中的文件不必固定在某个绝对位置,这种做法很好。LZE软件包描术文件lze-6.0- 2.spec中就定义了一个可重定位的前缀/usr(见第15行),这样,安装时就可将该包中在/usr目录下的文件重定位到用户指定的目录,如: # rpm -i --prefix /tmp lze-6.0-2.i386.rpm # 或者: # rpm -i --relocate /usr=/tmp lze-6.0-2.i386.rpm # 注: 此命令安装lze包,将其中含/usr重定位目录前缀的文件定位到/tmp目录。如包中 的/usr/bin/lze文件安装后,因重定位而成了/tmp/bin/lze。(RPM安装命令使用方法请参考<<精通RPM之二--安装篇>>) 4.2 Buildroot : 此域定义的是软件包所包含的文件共有的根目录,此根目录仅供RPM建立软件包时使用。即当RPM建立软件包时,将设定此目录为根(调用chroot函数),提取所需文件,生成软件包。 例如: 当Buildroot设定为/tmp时,对于LZE包描述文件中所包含的/usr/bin/lze文件,RPM实际打包的则是/tmp/usr/bin/lze,但对生成的包查询后可以发现:原文件名并未改变,还是/usr/bin/lze。 如此说来,这就很有意思了。一般用户通过设定Buildroot,也可以象超级用户(root)那样自由地建立各种各样的软件包了,即使包中有那些唯有超级用户才可以操作的目录或文件。安装这样的包与安装由超级用户建立的包,是没有什么分别的。 此域的描述格式很简单: Buildroot : 目录 如,上例可定义为: Buildroot : /tmp 5. 源码相关 下列四个域均是为制作源码包而设计的。源码包里有什么?用户可以通过查询包的文件列表得到,命令是“rpm -qpl 源码包文件”(请参阅<<精通RPM之五--查询篇>>有关内容)。一般情况下,源码包里有这么四类文件: 一是程序源码(SOURCE),二是源码补丁(PATCH),三是软件包描述文件,四是图标文件(ICON)。通过安装源码包,用户可以轻松地实现现场编译、连接和应用,同时更方便了软件开发者与软件包制作者:他们维护程序容易了,并且维护过后可以很快地生成执行代码包与源码包。这,也是所有人钟爱RPM 的重要原因之一。 5.1 Source : 此域定义RPM打包时要包含的程序源码文件。这些文件一般先用tar命令打包,然后再用gzip压缩。一个描述文件中可包含多个Source域,当有多个这样的域时,需要进行编号:第1个编为Source0(也可直接用Source),第2个编为Source1,第3个编为Source2等等。此域的描述格式为: Source[编号] : 源码文件 注: []所括为可选项。具体用法如: Source0 : lze-6.0-2.tar.gz Source1 : lzeime-wb-6.0-2.tar.gz Source2 : lzeime-py-6.0-2.tar.gz Source3 : lze-lib-6.0-2.tar.gz 注: 此域域值可以采用URL(统一资源定位)的形式,如LZE描述文件第14行。采用这种形式,主要是给其它用户提供该源码的位置信息。在RPM制作源包时, 它提取的是最后的文件名lze-6.0-2.tar.gz,而不是http://zhsoft.myetang.com/lze-6.0- 2.tar.gz(URL前面的内容被RPM忽略了)。 5.2 NoSource : 在上例中,假如在打包时不想包含Source1与Source2定义的文件,那该怎么办? 办法之一是将其所在行删除掉; 办法之二是将其所在行注释掉(即所在行前面加#号); 办法之三就是定义Nosource域,此域可重复。其描述格式为: NoSource : 源码域编号 本例可写作: NoSource : 1 NoSource : 2 注: 其中的1与2为编号,表示Source1和Source2。 注意: 如果软件包描述文件中没有NoSource域,则RPM生成的源码包名字格式为"软件名-版本号-释出号.src.rpm"。如果使用了NoSource 域,则RPM生成的源码包名字格式为"软件名-版本号-释出号.nosrc.rpm"(单从名字就可看出源码包包含的文件不完整)。 5.3 Patch : Patch的本义是补丁,用在这里指的是源程序的补丁,它是用diff命令比较新老源程序所产生的输出(命令为“diff -Nur 旧文件 新文件 >补丁文件”),而系统中的patch命令又可利用此输出将老版本的源程序升级为新版本。 此域定义RPM制作源码包时所要包含的补丁文件,该文件的命名建议用"软件名-版本号.补丁功能.patch"的格式。一个软件包描述文件中可有多个 Patch域,当有多个这样的域时,也需要象Source域那样进行编号(注:第1个域编为Patch0,也可省略0,用Patch)。 此域的描述格式为: Patch[编号] : 源码补丁文件 注: []所括为可选项。具体用法如: Patch0 : blather-4.5-bugfix.patch Patch1 : blather-4.5-config.patch Patch2 : blather-4.5-somethingelse.patch 注: 此域的域值也可以象Source域一样,采用URL的形式,RPM仅提取其中的文件名供其使用。 5.4 NoPatch : 此域的功能类似NoSource,其定义的编号对应的补丁文件RPM不作打包处理。此域在描述文件中可重复出现。如上例,若不想让源码包包含Patch0与Patch2域所指示的补丁文件,则可在描述文件写上这么两行: NoPatch : 0 NoPatch : 2 注意: 如果软件包描述文件中没有NoPatch域,则RPM生成的源码包名字格式为"软件名-版本号-释出号.src.rpm"。如果使用了NoPatch域, 则RPM生成的源码包名字格式为"软件名-版本号-释出号.nosrc.rpm"(单从名字就可看出源码包包含的文件不完整)。 三、功能段 见第19-86(即文件头以下的部分)。 何谓功能段?可以这么说,功能段是描述软件包的重要数据和操作指令的段落,它包括段名与段内容两部分。没有功能段,RPM便制作不出任何包裹文件。功能段的段名都是以百分号(%)开始的,占用一行。功能段的段内容范围是这样界定的:它从该功能段段名下一行开始到下一个功能段段名的前一行或到描述文件结束。如LZE描述文件,%description段是从第19行到第28行(%prep段从第29行开始),第19行为段名,第20-28行为段内容。而% prep段是从第29行到第32行(第33行%build段开始),其段名在第29行,段内容在第30-32行。另外要注意的是,各个功能段的位置是自由的,可放在文件头以下的任何位置,不必拘泥某一固定位置。 必选的功能段 描述文件中,必选的功能段有: 1. %description 本段是描述段,段的内容是对软件包进行较为详细的介绍,不象文件头的Summary域仅用一句话说明。介绍的文本形式自由,可任意换行,不受限制。具体请参见LZE描述文件第20-27行。 本段段名描述格式是: %description [子包选项] 其中,子包选项的格式为:[-n] 子包名 注: []所括为可选项。 三种形式的描述段段名: (1) 段名格式为“%description”时: 本功能段描述的内容是关于父包的。父包也可叫作主软件包,它用软件名来命令,其名字格式是:软件名-版本号-释出号.体系.rpm。如:lze-6.0-2.i386.rpm。 (2) 段名格式为“%description 子包名”时: 本功能段描述的内容是关于子包的。子包选项中没有-n选项时,子包是用软件名加子包名的形式命名,格式为: 软件名-子包名-版本号-释出号.体系.rpm。如分成两个子包的LZE软件:lze-bin-6.0-2.i386.rpm(执行程序包),lze- config-6.0-2.i386.rpm(配置文件包)。 (3) 段名格式为“%description -n 子包名”时: 本功能段描述的内容也是关于子包的。当子包选项中有-n选项时,子包直接采用子包名的形式命名。它不包含软件名,命名格式为: 子包名-版本号-释出号.体系.rpm。如分成两个子包的LZE软件: bin-6.0-2.i386.rpm(执行程序包),config-6.0-2.i386.rpm(配置文件包)。注意:这种类型的子包内容通常是可被其它软件包共用的函数库,如果专用,则尽量不要采用这样形式来定义子包。 2. %files 本段是文件段,它定义的是软件包需要包含哪些文件。本段通常放在描述文件尾部,以便于添加文件名,便于编辑。 本段段名描述格式为: %files [子包选项] [-f 文件名] 注: []所括为可选项。 当没有任何选项时,本段内容定义的是父包要打包的文件列表; 当有子包选项时,本段内容定义的则是子包要打包的文件列表; 当选择-f选项时,RPM除了从文件段读取打包文件列表外,还将从指定的文件中读取要打包的文件列表。指定的文件中,一个文件名占用一行。此选项方便了软件包制作者,他们可以通过程序自动产生有关软件的文件列表,并将其写入到一个特定的文件中,这样制作软件包时,只需引用一下这个文件,RPM就会自动从这个文件中读取文件名并将其加入包中。如果没有此选项,软件包制作者只能在文件段里,将要打包的文件名一个一个写进去,有点麻烦。 文件段的内容格式为: [修饰符1 [修饰符2] ...] 文件名 其中:修饰符是可选的,一个文件可以有多个修饰符,文件名必须以/开头(绝对路径形式)。 修饰符有以下几类: (1) 文件相关 * %doc : 此修饰符设定文件类型为说明文档(参见LZE描述文件第72,73行); * %config : 此修饰符设定文件类型为配置文件(参见LZE描述文件第70,71行); * %config(missingok) : 此修饰符设定文件类型为配置文件,且此文件可丢失。即使丢失了,RPM在卸载软件包时并不认为这是个错误,并不报错。 此修饰符通常用于那些软件包安装后建立的符号连接文件,如/etc/rc.d/rc2.d/S55named等。此类文件在软件包卸载后可能需要删除,所以丢失了也不要紧。 * %config(noreplace) : 此修饰符设定文件类型为配置文件,且如果安装时系统中有同名的文件,则软件包中的这个文件将换个名字安装,其文件名后缀加个.rpmnew。(如果不用此修饰符,则安装时RPM若发现有同名文件,则RPM会将系统中的这个文件换个名字,其后缀加上.rpmorig,而软件包中的文件则还用原来的名字。)在软件包卸载时,系统中的同名文件被RPM换个名字保存起来,其后缀加上了.rpmsave。 如描述文件的文件段中定义了这么一行: %config(noreplace) /etc/hello 则制成的包在安装时,若系统中已有此文件/etc/hello,则RPM会提示: warning: /etc/hello created as /etc/hello.rpmnew 这表明包中的/etc/hello文件被创建为/etc/hello.rpmnew文件了。 如果卸载这个软件包,则系统中的/etc/hello将会改名为/etc/hello.rpmsave。 * %ghost : 此修饰符所修饰的文件,其内容不被包含到软件包中。这样的文件一般是日志文件(log file)一类的文件,其文件属性(文件名,属主,属组等)很重要,但是文件内容并不重要。用此修饰符后,RPM仅将其文件属性加入包中。 * %attr : 此修饰符设定文件的属性信息,使用格式为: %attr(权限,属主,属组) 注: 权限常用数字形式(八进制),属主和属组可以是数字,也可以是字符串。如果文件的权限,属主和属组想使用系统默认值,则可用减号(-)表示它。 如下例采用两个修饰符,定义/etc/funkey.def文件的权限为755,属主默认,属组为root,类型为配置文件: %attr(755,-,root) %config /etc/funkey.def * %verify : 此修饰符设定文件需要校验的那些属性。这些属性有:owner(属主),group(属组),mode(权限),md5(MD5检查和),size(大小),maj(主设备号),min(从设备号),symlink(符号连接),mtime(最后修改时间)。 此修饰符使用格式为: %verify([not] owner group mode md5 size maj min symlink mtime) 注: not可选。当选用not时,表明需要校验除选定属性以外的那些属性。 如下例指示RPM校验/dev/ttyS0文件时,要校验其权限,MD5检查和,大小,主设备号,从设备号,符号连接和最后修改时间共七项属性信息: %verify(mode md5 size maj min symlink mtime) /dev/ttyS0 这也可以采用not选项来实现,因为除去属主owner和属组group两项属性,剩下的就是需要校验的属性了: %verify(not owner group) /dev/ttyS0 (2) 目录相关 * %docdir : 此修饰符定义说明文档前缀,这样,后面所有含指定文件名作为前缀的文件,RPM打包时会将其类型统一设定为说明文档。 例如某描述文件的文件段中有这么三行: /root/readme %docdir /root /root/mydoc.txt 此例指明/root为说明文档的前缀,因为/root/mydoc.txt在%docdir的下一行,所以RPM打包时会设定此文件的类型为说明文档。而/root/readme文件则不做此设定,因为它在%docdir定义之前。 通过此修饰符,用户可以很方便地设定说明文档一类的文件,因为它们通常固定在某个目录下面,有着共同的前缀。 * %dir : RPM在制作软件包时,如果要打包的文件是个目录,那么RPM会将该目录下面的所有文件包含到软件包中。(注意:如果要打包的文件是个符号连接,此符号连接又指向一个目录,则RPM并不会将其视作目录,只会把它当为普通文件处理。)如果仅想将这个目录名包含到软件包中,制作者用此修饰符修饰一下这个目录名就行了。 如: /etc是个系统目录,其下有多个文件,如果想将其均加入包中,描述文件的文件段里可写上这么一行: /etc 如果仅想包含此目录,则可用: %dir /etc (3) 另类修饰符 此类只有一个%defattr。说它是另类修饰符,是由于它设定的是默认的文件属性,而非特定的某个文件。它一般放在文件段内容的第一行。 其使用格式为: %defattr(权限,属主,属组) 其中: 权限,属主和属组都可以使用减号(-)。使用减号的属性将由系统设定。 例如: %defattr(022,zzz,zhsoft) 设定其后的所有文件权限为022,属主为zzz,属组为zhsoft;又如: %defattr(-,zzz,-) 则是设定其后的所有文件属主为zzz,权限与属组由系统设置。 可选的功能段 描述文件中,可选功能段的内容都是些脚本程序。(LZE描述文件中多个脚本程序中仅含一个echo命令) 可选的功能段的描述格式为: 功能段名 [子包选项] 注: 子包选项为"[-n] 子包名"。当无子包选项时,段内容描述的是父包的脚本程序。当有子包选项时,段内容则是描述子包的脚本程序。 可选的功能段可分为如下三类: 1. 建包用功能段: RPM通过源程序来建立一个软件包时,要执行预处理,编译,安装和清理四项操作,分别对应于%prep,%build,%install和%clean四个段。 下面按其执行顺序逐段进行说明: 1.1 %prep : 此为预处理段,其内容为预处理脚本程序。该程序完成以下任务: * 建立软件编译用目录; * 将源程序解压缩; * 通过打补丁,升级源程序; * 执行其它一些操作,使源程序随时可进行编译。 在此脚本程序中,可使用如下两个宏命令: 1.1.1 %setup 这个宏利用系统中的gzip与tar等命令,来解压源程序包。RPM会自动探测源程序包是否压缩,如果压缩,它会用gzip将其解压缩,否则直接用tar命令展开包中文件。其使用格式为: %setup [-n name] [-c] [-D] [-T] [-b N] [-a N] 注: []所括为可选项。 (1) 当没有任何选项时: 这个宏用来解压默认的源程序包(由文件头Source或Source0域指定)。注意:源程序包中的文件应用"软件名-版本号"作为其上层目录,这样% setup宏就可以正常工作。如果不以"软件名-版本号"作为其上层目录,则%setup宏工作时有一个指令"cd 软件名-版本号"(转目录)会因为系统中没有此目录而出错退出(除非在此宏上面加上建立此目录的命令)。如LZE软件源程序所在的目录为lze-6.0, 我需要用命令"tar cvzf lze-6.0-2.src.tgz lze-6.0"将源程序打包并压缩,这样的包就可以被%setup宏正确使用了。 下面是%setup宏命令所执行的一系列命令: (指令前面为行号) 1 cd /usr/src/dist/BUILD 2 echo "预处理脚本程序(prep)开始执行" 3 cd /usr/src/dist/BUILD 4 rm -rf lze-6.0 5 /bin/gzip -dc /usr/src/dist/SOURCES/lze-6.0-2.src.tgz | tar -xvvf - 6 STATUS=$? 7 if [ $STATUS -ne 0 ]; then 8exit $STATUS 9 fi 10 cd lze-6.0 11 [ `/usr/bin/id -u` = '0' ] && /bin/chown -Rhf root . 12 [ `/usr/bin/id -u` = '0' ] && /bin/chgrp -Rhf root . 13 /bin/chmod -Rf a+rX,g-w,o-w . 14 exit 1 看,第10行就有一个转到lze-6.0目录的命令,如果没有这个目录,程序就会出错退出了。也许你要问:这些指令你是怎么知道的?其实这很简单,只要在%setup宏下面加上一句"exit 1"命令,让预处理脚本程序非正常退出即可。这样RPM所执行的预处理脚本程序作为临时文件在其退出时并未删除,只要看一下这个文件(在/var/tmp目录下以rpm-tmp开头)就知道%setup宏命令做什么了。 (2) -n name : 上面已经谈到,源程序包中的文件应采用"软件名-版本号"作为上层目录。如果用了别的什么目录(如name),%setup宏无法正常工作,那该怎么办? 没关系,可以用-n选项,引用一下这个目录(name)就行了。假如我的LZE源程序包中的文件是以lze为上层目录,那么我就可以用"%setup -n lze"宏命令来解压缩该包。 (3) -c : 此选项的作用是创建上层目录("软件名-版本号"目录)并转到这个目录。对于LZE软件,其效果相当于在上例的第4行与第5行之间加上这么两行命令: mkdir -p lze-6.0 cd lze-6.0 它适用的情况是:有的源程序包是在源程序所在目录下打的包,所以其中的文件都没有上层目录。这样的话,要想正确解压,必须创建上层目录。 (4) -D : 本选项的作用是在解压源程序包之前不要删除软件的上层目录(软件名-版本号)。在上例中,其效果是不执行第4行的命令(rm -rf lze-6.0)。 (5) -T : 本选项的作用是不解压默认的源程序包(由文件头的Source或Source0域所定义)。在上例中,其效果是不执行第5-9行的命令:第5行是解压源程序包(用gzip -dc将包的内容解压缩到管道中,再由tar -xvvf -从管道中读取数据并展开),第6-9行是检查解压命令的返回值,非0时执行非正常退出。 (6) -b N : 本选项指示RPM在转到上层目录前解压第N个源程序包(由文件头SourceN域定义)。这适用于含上层目录的源程序包。注意:如果使用此选项时不同时使用-T选项,则RPM解压的是两个源程序包,一个是默认的包(由Source或Source0域定义),一个是-b选项指定的包(由SourceN域定义)。这样,当N等于0时,默认的源程序包将被解压两次。所以,如果想仅解压指定源程序包,请同时使用-T选项,以禁止解压默认的源程序包。 下面的宏命令仅解压第1个源程序包,然后转到上层目录: %setup -b 1 -T (7) -a N :本选项指示RPM在转到上层目录后再解压第N个源程序包(由文件头SourceN域定义)。这适用于不含上层目录的源程序包。使用本选项时,一般加上- c选项,以创建上层目录并转到此目录。注意:如果使用此选项时不同时使用-T选项,则RPM解压的是两个源程序包,一个是默认的包(由Source或 Source0域定义),一个是-a选项指定的包(由SourceN域定义)。这样,当N等于0时,默认的源程序包将被解压两次。所以,如果想仅解压指定源程序包,请同时使用-T选项,以禁止解压默认的源程序包。 下面的宏命令让RPM先转到上层目录,再仅解压第2个源程序包: %setup -T -a 2 1.1.2 %patch 此宏利用系统中的patch命令,来给指定的源程序包打补丁,从而将程序升级。其使用格式为: %patch [-P N] [-p N] [-b name] [-E] 注: []所括为可选项。 为了说明下列选项的作用,我们为LZE软件包描述文件中定义三个补丁文件: Patch0 : lze-patch.zero Patch1 : lze-patch.one Patch2 : lze-patch.three (1) 当没有任何选项时: 没有任何选项时,该宏使用的是默认的补丁文件(第0个补丁文件),即由文件头Patch或Patch0域所定义的文件(LZE包使用lze-patch.zero)。 该宏在执行时,扩展为以下指令: echo "Patch #0:" patch -p0 -s < /usr/src/dist/SOURCES/lze-patch.zero 注: 第一行指令是利用echo命令向屏幕输出字符串“Patch #0:”。第二行指令则是利用patch命令读取补丁文件lze-patch.zero升级源程序。 patch命令用了两个选项:(有关patch命令用法,详见其用户手册) * -p : 这个选项用于确定patch所要操作的文件。它针对补丁文件头部的文件名,删除名字中指定数目个斜杠(/)前面的所有字符,从而得到要操作的文件名。如补丁文件里有个文件名/usr/zzz/src/lze.c,则用-p0时patch操作的文件名不变,用-p1时则变为 usr/zzz/src/lze.c,用-p2时则变为zzz/src/lze.c,如用-p4则操作的文件名变为lze.c。 * -s : 这个选项指示patch在打补丁过程中不输出任何信息,即使有错误发生。 (2) -P N : 使用此选项以指示RPM使用第N个补丁文件(由文件头PatchN域定义)。如想让RPM使用LZE的第2个补丁文件Patch2(lze-patch.three)时,可使用"-P 2"来指定。 (3) -p N : 此选项与其参数是由%patch宏直接传给patch命令的。请参见上面patch命令所用的-p选项的介绍。 (4) -b name : 当有多个patch命令操作同一个文件时,patch会将原文件换名保存(其后缀变作.orig),如lze.c会变作lze.orig。如果想用别的名字作后缀,则可用-b设置一下,这样原文件会换名为"原文件名+后缀",如用-b ZZZ时,lze.c会换名保存为lze.cZZZ。 此选项在执行时,实际上是给patch命令传递了一个选项及参数,即--suffix name。 (5) -E : 此选项直接传给patch命令,其作用是:如果一个文件打完补丁后内容为空(字节数为0),则删除这个文件。 1.2 %build : 此为编译段,其内容为编译脚本程序。该程序完成源程序的编译和连接。一个最简单的例子就是程序中仅有一个make命令。这适用于大部分情况,因为多数软件均有自己的makefile,这样通过make命令就可实现编译与连接。如果没有makefile的话,需要软件包制作者自己在编译段书写上一系列的编译连接命令。 1.3 %install : 此为安装段,其内容是安装脚本程序。该程序将已编译连接好的执行程序或其它文件存放到指定目录下,这些程序或文件供RPM打包时使用。一个最简单的例子就是程序中仅用一个make install命令,从而完成安装。这也需要相应的软件有makefile维护文件。没有的话,软件包制作者也得自己写指令。 1.4 %clean : 此为清理段,其内容是清理脚本程序。此程序在RPM制作好软件包后才执行,它通常是删除那些编译连接时产生的临时文件或目录,完成缮后工作。 2. 管理用功能段: 此类段用于软件包自身的管理(安装,卸载和校验),包括%pre,%post,%preun,%postun,和%verifyscript五个功能段。 2.1 %pre : 该段内容为安装前脚本程序。它在软件包安装之前执行,通常是检测操作环境,建立有关目录,清理多余文件等等,为软件包的顺利安装做准备。本段很少使用。 其段名格式为: %pre [子包选项] 2.2 %post : 该段内容为安装后脚本程序。它在软件包安装完成之后执行,常用来建立符号连接,修改系统配置文件,运行ldconfig程序等,以利软件的正常运行。 其段名格式为: %post [子包选项] 2.3 %preun : 该段内容为卸载前脚本程序。它在软件包卸载之前执行,主要为卸载做准备。具体如,要卸载的软件包中某个程序当前正在运行时,此脚本程序必须杀掉它,否则无法正确卸载。 其段名格式为: %preun [子包选项] 2.4 %postun : 该段内容为卸载后脚本程序。它在软件包卸载后执行,完成卸载的缮后工作,如将系统配置文件inetd.conf改回原来的样子,重新运行一下ldconfig命令,将已卸载的共享库从缓冲文件ld.so.cache中删除等等。 其段名格式为: %postun [子包选项] 2.5 %verifyscript : 该段内容为校验脚本程序。RPM校验软件包时,除了执行标准的校验外,如果软件包制作者设定有此校验脚本程序,还将执行之。 其段名格式为: %verifyscript [子包选项] 下面是XFree86-libs-3.3.6-6.i386.rpm软件包中的校验脚本程序,它校验的是动态链接库目录/usr/X11R6/lib。校验时,在/etc/ld.so.cache文件中查找/usr/X11R6/lib,如果找不到,则显示"missing",找到则显示"found"。 # verifyscript echo -n "Looking for /usr/X11R6/lib in /etc/ld.so.conf... " if ! grep "^/usr/X11R6/lib$" /etc/ld.so.conf > /dev/null then echo "missing" echo "/usr/X11R6/lib missing from /etc/ld.so.conf" >&2 else echo "found" fi 3. 交互用功能段: 这类功能段有%triggerin,%triggerun,%triggerpostun,它们的内容都是RPM用于软件包之间交互控制的脚本程序。这些脚本程序都是在系统满足指定的条件下才触发执行的: 1) %triggerin : 段内为安装时触发脚本程序,当其所在软件包与指定软件包仅有一方已安装时,安装另一方将触发此程序执行; 2) %triggerun : 段内为卸载时触发脚本程序,当其所在软件包与指定软件包都已安装时,卸载二者中的任一个将触发此程序执行; 3) %triggerpostun : 段内为卸载后触发脚本程序,只有指定软件包卸载后才触发此程序执行。 3.1 段名格式 它们的段名描述格式均为: 交互段名 [子包选项] [-p 解释程序] -- 触发条件1 [,触发条件2] ... 注: []所括为可选项。子包选项见前面介绍,不赘述。 3.1.1 -p选项: 此选项用于指定一个解释程序,来解释执行交互功能段的脚本程序。默认情况下,RPM使 用/bin/sh来执行脚本(此类脚本用SHELL语言编写,也叫SHELL程序)。有的RPM包则是使用/usr/bin/perl 来执行脚本(此类脚本是用PERL这种解释性语言写的),这就需要用-p选项来指定解释程序为 /usr/bin/perl,如: %triggerin -- sendmail ln -sf /usr/bin/sendmail /etc/mymailer/mailer %triggerin -- vmail ln -sf /usr/bin/vmail /etc/mymailer/mailer 注: 此例中定义package子软件包安装时触发脚本程序:当触发条件(fileutils>3.0,perl<1.2)满足时,用/usr/bin/perl执行脚本,即用print命令输出字符串"I'm in my trigger!"。 3.1.2 触发条件: 交互功能段的触发条件格式是: 功能名 [比较符 版本号] 其中:比较符与版本号可选。仅有一个功能名时,表明该功能存在时触发程序执行。比较符可用大于(>),等于(=),小于(<),大于等于(>=)和小于等于(<=)。 如触发条件bash,又如触发条件fileutils>3.0,这种使用均合法。 交互功能段最少有一个触发条件。当有多个触发条件时,这些条件间均以逗号(,)分隔,它们之间是"或"的关系,即只要其中有一个条件系统满足,RPM就将执行触发脚本程序。如上面介绍-p选项时举的例子:例子中有两个触发条件fileutils>3.0和perl<1.2,在安装软件包时,只要有一个条件满足,RPM就会执行触发脚本,即输出"I'm in my trigger!"。 3.2 交互用功能段的使用 为什么要使用交互用功能段?下面的例子很能说明问题。 假定mymailer软件包需要/etc/mymailer/mailer这个符号连接文件指向当前使用的邮件发送**程序。如果sendmail包安装了,那么这个符号连接文件应指向/usr/bin/sendmail程序。如果vmail包安装了,那么它应当指向/usr/bin/vmail程序。如果这两个软件包都安装了(实际上,sendmail与vmail彼此是冲突的),那么我们也无需考虑符号连接指向哪个文件了。当然,如果这两个包都未安装,那么/etc/mymailer/mailer符号连接文件也没有理由存在了。 上述要求,我们通过为mymailer软件包编写触发脚本程序来实现,这些脚本程序在下列事件发生时,将改变/etc/mymailer/mailer符号连接的内容: 1) sendmail已安装; 2) vmail已安装; 3) sendmail卸载时; 4) vmail卸载时。 前两个事件触发的脚本程序可以这样写: %triggerin -- sendmail ln -sf /usr/bin/sendmail /etc/mymailer/mailer %triggerin -- vmail ln -sf /usr/bin/vmail /etc/mymailer/mailer 这是两个安装时被sendmail或vmail所触发脚本程序。它们将在下列情况下执行: 1) 在mymailer包已安装的情况下,安装或升级sendmail包; 2) 在mymailer包已安装的情况下,安装或升级vmail包; 3) 在sendmail包已安装的情况下,安装或升级mymailer包; 4) 在vmail包已安装的情况下,安装或升级mymailer包。 后两个事件触发的脚本程序可以这么写: %triggerun -- sendmail [ $2 = 0 ] || exit 0 if [ -f /usr/bin/vmail ] then ln -sf /usr/bin/vmail /etc/mymailer/mailer else rm -f /etc/mymailer/mailer fi %triggerun -- vmail [ $2 = 0 ] || exit 0 if [ -f /usr/bin/sendmail ] then ln -sf /usr/bin/sendmail /etc/mymailer/mailer else rm -f /etc/mymailer/mailer fi 这两个脚本程序在下列情况下触发执行: 1) 在sendmail包已安装的情况下,卸载mymailer包; 2) 在vmail包已安装的情况下,卸载mymailer包; 3) 在mymailer包已安装的情况下,卸载sendmail包; 4) 在mymailer包已安装的情况下,卸载vmail包。 为了确保在mymailer包卸载后符号连接文件/etc/mymailer/mailer也被删除,可以在 mymailer软件包描述文件的%postun功能段内,加上删除该文件的命令: %postun [ $1 = 0 ] && rm -f /etc/mymailer/mailer 注: %postun段内为卸载后执行脚本程序,在mymailer包卸载后执行。 由上看出,当一个软件包与另一个软件包存在密切关系时,我们可以通过交互用功能段实现某些文件的管理,这不仅扩展了RPM软件包管理的功能,又有助于软件包的正常运行。 4. 其它功能段 其它功能段只有一个,即%changelog。这个段的内容是软件维护记录,它记录每次软件维护的时间,维护人及其EMAIL,维护的项目等。 %changelog段内容格式为: * 星期 月份 日子 年份 维护内容 注: 每个维护记录均以*开头,星期,月份均须为英文缩写。维护内容多时可分行编写, 每行开头最好以减号(-)开头。可以采用类似LZE方式的维护记录写作格式:(见LZE描述文件第80-85行) * 星期 月份 日子 年份 维护人 EMAIL - 维护内容1 - 维护内容2 - ...... (其它维护内容) (责任编辑 尤北 [email protected]) |
另外,上面还缺两个链接 升级篇,卸载篇
http://www0.ccidnet.com/tech/focus/i...name=serialize
http://www0.ccidnet.com/tech/guide/2...9/58_3815.html
http://www0.ccidnet.com/tech/guide/2...0/58_3831.html
作者: bbbush 发布时间: 2005-04-19
还是不知道哪里定义了变量。
如何写自己的宏?
还需要找 rpm 的手册页,以及其他随机文档,还有 fedora extras, freshrpms 这些网站提供的各种 rpm 构建工具,还有仓库建设的工具。 上面提到的那些自动生成 spec 的工具也要研究一下,不过既然都需要手动修改,那么就提高不了多少效率。rpmlint 辅助工具有人研究过吗?autopackage 如果能做 rpm 就好了...
作者: bbbush 发布时间: 2005-04-19
还是邮件列表的噪音比较小。
宏与变量总是不同的
http://www.redhat.com/archives/rpm-l.../msg00110.html
Konstantin Riabitsev
Hello: Just a quick question -- I'm wondering which is considered "more proper": %{buildroot} or $RPM_BUILD_ROOT? I tend to use %{buildroot} as it is shorter and more consistent with the rest of the spec file, but I'd like an official opinion. Regards, |
Matthias Saou
Sorry, but just an unofficial opinion here : I also tend to use %{buildroot}, and also %{optflags} etc. instead of their $RPM_* equivalents mostly since I find it more readable, a bit shorter, and that Red Hat guys seemed to be doing the same too. Matthias |
http://www.redhat.com/archives/rpm-l.../msg00133.html
Rob Nagler
Not sure this is correct. Maybe this has been fixed after 4.0.4, but when I do: %files -f $RPM_BUILD_ROOT/files.list I get: RPM build errors: Could not open %files file ./$RPM_BUILD_ROOT/files.list: No such file or directory When I do: %files -f %{buildroot}/files.list It works fine. Rob |
http://www.redhat.com/archives/rpm-l.../msg00145.html
James Olin Oden
Don't the macros get evaluated before the script is ran and the value of $RPM_BUILD_ROOT is evaluated in the script? ...james |
http://www.redhat.com/archives/rpm-l.../msg00134.html
Jeff Johnson
> Jeff Johnson writes: > > Otherwise, the two have identical values and uses, and it really doesn't > > matter at all. > > Not sure this is correct. Maybe this has been fixed after 4.0.4, but > when I do: > Yes it is a correct statement ... > %files -f $RPM_BUILD_ROOT/files.list ... but this syntax is not officially supported functionality any more than %{buildroot} is. > > I get: > > RPM build errors: > Could not open %files file ./$RPM_BUILD_ROOT/files.list: No such file or directory > > When I do: > > %files -f %{buildroot}/files.list > Yup, %files is not a shell context, but rather a spec file context, so $RPM_BUILD_ROOT is not defined but %{buildroot} is. Again, It Really Doesn't Matter. 73 de Jeff |
作者: bbbush 发布时间: 2005-04-19
RPM_SOURCE_DIR RPM_BUILD_DIR question A R Hummaida hi how could one retrieve the SRPM_SOURCE DIR/BUILD_DIR etc dynamically ie without knowledge that on a Redhat they exist in /usr/src/redhat/SOURCES etc ? the rcfile includes them and exports them to the bash environment but "printenv" does not show them. this is on RH 7.2 with rpm-4.0.3 any input. Many Thanks A.Hummaida |
http://www.kdevelop.org/?filename=users.html
http://kpp.sourceforge.net Kpp - A RPM Spec file generator with KDevelop support |
--
这个是完全无关的东西
http://toolbox.xilinx.com/docsan/xil..._write_rpm.htm
RPM A Relationally Placed Macro (RPM) defines the spatial relationship of the primitives that constitute its logic. An indivisible block of logic elements that are placed as a unit into a design. Use the Floorplanner interactive graphical tool to perform the following functions on your designs: * Doing detailed-level floorplanning * Creating an RPM core that can be used in other designs * Viewing and editing location constraints * Finding logic or nets by name or connectivity * Cross-probing from the Timing Analyzer to the Floorplanner * Placing ports automatically for modular design The graphical user interface includes pull-down menus and toolbar buttons that contain all of the necessary commands for changing the design hierarchy, floorplanning, and performing design rule checks. Dialog boxes allow you to set parameters and options for command execution. |
片言只字。搜索 google 有关 rpm macro fedora 会找到各种更有趣的东西
http://www.redhat.com/archives/rpm-l.../msg00171.html FWIW, the really nasty implementation detail is a maximum of 65Kb on the expansion buffer, with silent truncation if reached. The buffer could/should be dynamically reallocated if (or rather when) necessary. There's been little reason to do so (recursive realloc's make my head hurt a lot), as no one that I know of has hit the 65 Kb limit yet. 73 de Jeff |
Getting started with RPM building
Someone once asked, “How do I go about learning about all this RPM goodness?” Here's what I did/do: * Read the online copy of Maximum RPM * Poke through the .spec files in the source packages (SRPMS) that come with your distribution. GNU Midnight Commander (mc) will do all the cpio magic behind the scenes so you can explore source packages quickly and easily. If you don't have mc on your local system, you can unpack an SRPM manually: rpm2cpio foo-1.23.src.rpm | cpio -id * Macros are at the core of RPM packaging. There are macros for everything: directory locations, compiler optimizations, etc. On Red Hat and Fedora systems, you'll want to look at all the macros files in the /usr/lib/rpm directory tree. You can locate them all in one fell swoop: find /usr/lib/rpm -name macros * Grok a copy of cpan2rpm; you'll learn some cool things about packaging Perl CPAN modules. (Or you can just use cpan2rpm and not worry about the details. :-) * If you end up doing a lot of RPM work, join the rpm-list mailing list. In particular, Jeff Johnson, the lead RPM developer at Red Hat, is very helpful—and usually very quick to answer questions. This article is licensed under a Creative Commons License. |
http://fedoranews.org/alex/tutorial/rpm/index.shtml
All you have to know about RPM
by Alexandre de Abreu
Updated on Tuesday, 09-Mar-2004 05:00:36 PST
Everybody knows that Fedora and Red Hat Linux use RPM as a package management tool as well as update tools(yum, up2date, apt) use rpmlib for accessing the rpm data on the system. It's really nice when we do a "yum install XFree86-xdm" and all dependency calculations, space available are done only by answering "y" to a few questions. But what to do when setup is not ready for using yum or other install/update tool? On the next article I'll show an easy way for yum repository building with wget and how to use it, see Hal Canary's rsync script for an example. The problems will be shown here starting from "How to install" famous rpm commands and then going to more interesting ones. Follow a link or go to next page by clicking on the blue arrow below. How can I... Problem 1: Install or Upgrade a package? Can I install an old one? Problem 2: Remove a package? Is it going to remove any dependencies? Problem 3: Query installed packages? What about a RPM file? Problem 4: List what packages are required by some RPM package? Problem 5: Find from which package the file /usr/bin/smbmount belongs? Problem 6: List what files will be installed by a RPM package? Problem 7: Install a package directly from Internet? Can I use a proxy? Problem 8: Simulate what will be done when executing "rpm -ivh new-kernel.rpm"? Problem 9: Upgrade all my installed packages with one Freshen command? Problem 10: Figure out the Kernel version(smp, bigmem) and base arch(i386, athlon)? Problem 11: Install a new Kernel version but keeping my old one installed? Problem 12: Make backups of my old packages when updating or removing them? Problem 13: Build a RPM package from a SRPM with rpmbuild? Problem 14: Check digests and signatures against a package? Problem 15: See what RPM macros are defined on my system? Problem 16: Get rpm back? The command "rpm -qa" returns nothing! Problem 17: Figure out the installation time of my packages? [User Contribution] Problem 18: Figure out the size of a installed package? [User Contribution] |
http://fedoraproject.org/wiki/Extras_2fRPMMacros
Valid RPM Macros
Here are the definitions for some common specfile macros as they are defined on Fedora Core 3 (rpm-4.3.2-21). For definitions of more macros, examine the output of "rpm --showrc". To see the expanded definition of a macro use the command "rpm --eval '%{macro}'". Note that neither command will take into account macros defined inside specfiles, but both will take into account macros defined in your ~/.rpmmacros file and macros defined on the command line. Macros mimicking autoconf variables %{_sysconfdir} /etc %{_initrddir} %{_sysconfdir}/rc.d/init.d %{_prefix} /usr %{_exec_prefix} %{_prefix} %{_bindir} %{_exec_prefix}/bin %{_lib} lib %{_libdir} %{_exec_prefix}/%{_lib} %{_libexecdir} %{_exec_prefix}/libexec %{_sbindir} %{_exec_prefix}/sbin %{_sharedstatedir} %{_prefix}/com %{_datadir} %{_prefix}/share %{_includedir} %{_prefix}/include %{_oldincludedir} /usr/include %{_infodir} /usr/share/info %{_mandir} /usr/share/man %{_localstatedir} /var RPM directory macros %{_topdir} %{_usrsrc}/redhat %{_builddir} %{_topdir}/BUILD %{_rpmdir} %{_topdir}/RPMS %{_sourcedir} %{_topdir}/SOURCES %{_specdir} %{_topdir}/SPECS %{_srcrpmdir} %{_topdir}/SRPMS Build flags macros %{_global_cflags} -O2 -g -pipe %{_optflags} %{__global_cflags} -m32 -march=i386 -mtune=pentium4 # if redhat-rpm-config is installed Other macros %{_var} /var %{_tmppath} %{_var}/tmp %{_usr} /usr %{_usrsrc} %{_usr}/src Reference Here are macros from other distributions to aid you in package conversion. * PLD RPM Macros http://fedoraproject.org/wiki/Extras...os_20Reference * Mandrake RPM Macros http://fedoraproject.org/wiki/Extras...os_20Reference |
http://lists.freshrpms.net/pipermail...ry/007472.html
http://www.fedora.us/docs/rpm-packaging-guidelines.html
GNOME RPM spec file packaging guidelines
Gregory Leblanc
GNOME
GNOME Packaing Project
Abstract This document attempts to outline the guidelines that GPP spec files should adhere to. These guidelines are designed to make spec files that will function on at least Red Hat 6.x and 7.x. They should also function on Red Hat-like systems with only minor adjustments. For systems that use RPM but aren't Red Hat-like, these spec files should serve as a good starting point. Some knowledge of writing RPM spec files is assumed. The book Maximum RPM has a good intro to some of the concepts and syntax used in RPM spec files. |
作者: bbbush 发布时间: 2005-04-19
几百k 的一个文件, 但是没法传上来
另外,编写 rpm macro 的最好的教程,看来和 hal 之类一样, 在源代码里面才有。
谁发一份 rpm-devel-4.4 的源代码里面的文档呢, 打个包发上来
update 20050423:
那份教材好像是 max 的改写,没什么意思。 另外,编写 rpm macro 的教程也没有找到,也许不是很难,所以连语法都没有了 :ask
最好的教材还是 max 等等几本英文的很旧的书籍,IBM dw 的两篇,ccid 的9篇连载。
update 20050428:
http://www.rpm.org/max-rpm-snapshot/index.html 比较新的 max rpm, 使用的是 OPL。版权问题最讨厌了。要翻译的话,可以从 sgml 源文件开始,不要直接翻译 html
update 20050502:
Guru Labs 的教材翻译完了
-
作者: bbbush 发布时间: 2005-04-20
Guru Labs
《Creating RPMs (Student version)》v1.0 (创建 RPM 打包,学生版)
本文目的 1. 作为我们的教学课件的范例用于评估 2. 为系统管理员提供高质量的 RPM 手册
有关本教程 您看到的蓝色背景,模拟了印刷 Guru Labs 课件所用的自定义纸张。学生版不包括教师版中的指令备注和教学提示。
有关我们特别的排版信息,参见 http://www.gurulabs.com/courseware/c...are_layout.php
有关我们提供的免费教学内容,包括本文的最新版,参见 http://www.gurulabs.com/goodies/
范例在以下平台中得到验证 rhel4, fc3, suse9, suse9.2
关于 Guru Labs
Guru Labs 是一个 Linux 培训公司,由 Linux 专家创建于 1999,提供最好的 Linux 培训和课件。全面的内容请参见 http://www.gurulabs.com
Copyright Guru Labs, L.C. 2005
Licensed under the Creative Commons Attribution-NonCommercial-NoDerivs License. http://creativecommons.org/licenses/by-nc-nd/2.0 (译文违反了许可,但是我想这份许可的 -nd- 是由于采用了特殊的背景和排版,而不是因为翻译能涉及到的那些 (应当) 人所共知的知识?)
Guru Labs 801 N 500 W Ste 202 Bountiful, UT 84010 Ph: 801-298-5227
http://WWW.GURULABS.COM
Page 1
目标
* 理解 UNIX/Linux 软件管理的历史概况
* 描述 RPM 系统的特点与结构
* RPM 的日常应用,各种不同的 RPM 打包的处理
* 修改并重构建已有的 SRPMS
* 学习 RPM SPEC 文件的语法,以及编译基础要求
* 创建新的 SPEC 文件,辅助文件以及 RPM 文件
* 高级的 RPM 创建技术
* 处理 Redhat 与 SuSE 发行版中,RPM 系统的不同之处
Page 2
处理打包
Unix 打包 (System V packages)
Linux 打包 (Slackware Tarballs, RPMs, Debian DPKGs)
传统上,UNIX 系统的软件都是以源代码形式发布的。要使用某个软件,管理员必须为要运行它的系统适当地编译它,然后安装它。如果它要求任何辅助的软件包, 那么也必须同时安装。如果要求本地进行任何定制,那么就必须去配置。
如果软件需要升级,管理员必须找到系统中, 属于这个软件的所有文件,替换为升级的版本,小心地保留那些本地作出的配置修改。
现在,考虑一个典型的 UNIX 工作站应用程序,例如 Mozilla。基本的 Mozilla 应用程序包含大约 495 个文件,分布在大约 10 个不同的目录中。在删除时,管理员必须找到所有这些文件并且删除。在升级时,管理员必须手工地替换所有文件。在运行时,Mozilla 要求安装大约 50 种其他可执行文件和运行时库 (而这些又会依赖于其他库文件)。
手工管理所有这些不是不可能的, 并且 Unix 管理员已经这样做了三十多年了,不过,很多服务提供商开发了简化此类工作的工具。在商业 Unix 世界中,System V Unix 定义了一种标准“打包”系统,这成为了此类软件的基础,包括 Solaris 中使用的 pkg 格式,还有 HP-UX 中使用的 depot 格式。这些软件包系统提供了各种工具,可以用来安装、卸载和升级打包中的软件。打包中包含了软件和元数据 (例如列举出为了使软件可以运作,必须安装的其他软件等等)。
在 Linux 世界中,最初的软件没有打包,与 Unix 世界中完全相同。后来,在 1993 年 Slackware 发行版出现时,它引进了一种很初级的打包格式。之后,两种新的发行版,Redhat 与 Debian,都开始为 Linux 开发更多功能的打包软件。Debian 引进了 DPKG 打包系统,而 Redhat 引进了 RPM 打包系统。从那时开始, RPM 打包系统成为了 Linux 社区中的事实标准。它为几乎所有著名商业 Linux 发行版所用,包括来自 Redhat, SuSE 和 Mandrake 的那些。RPM 也是 Linux 世界中软件包管理的法律标准, Linux 标准化组织 LSB (Linux Standards Base) 要求相容于 LSB 的系统支持 RPM 文件的安装。
Page 3
RPM 特性
非交互安装,可运行脚本,可追踪/校验/查询已安装的文件,可追踪依赖性关系,可追踪整个源代码和编译过程,数字签名
RPM, RPM 包管理工具,提供了各种特性,使之成为 Linux 社区中杰出的包管理工具,大大简化了 Linux 管理员的工作。
RPM 提供了一系列的工具,可以用来实现非交互地,可运行脚本的安装过程。当软件安装之后,RPM 提供的工具可以用来追踪已安装的文件,使得卸载和升级非常简单,管理员可以检查软件安装是否正确,已安装的文件是否被修改过。另外,RPM 提供了一系列工具,可以用来查找已安装的文件,判断哪些程序在使用它们。
RPM 有杰出的依赖性追踪能力,意味着在安装新软件包时,它可以保证为了运行新软件,所有必需的软件都已经安装。在卸载软件时,它可以首先检测操作是否会影响其他应用程序。
另外,RPM 提供了一系列工具,管理从打补丁、配置直到编译的整个过程。当编译一个软件时,RPM 可以从原始的源代码开始,生成所需的补丁,将打补丁,配置源代码和编译源代码以产生可执行文件的过程脚本化。RPM 的这种功能极大地简化了企业中自定义软件的维护过程。
最后,RPM 允许将所有已打包的软件签名,使用公钥技术。这种特性允许验证 RPM 的可靠性,防止安装木马程序。
Page 4
RPM 结构
RPM 打包文件,数据库 /var/lib/rpm,工具 rpm,rpmbuild,rpmsign,rpm2cpio,RPM 配置文件 宏
RPM 系统包含多个组件。要使用 RPM 安装的软件必须打包成特定的格式,RPM 打包文件。RPM 打包文件是一个存档文件,包含了要安装的文件,以及元数据。RPM 系统使用元数据来保证将文件以正确的权限和所有者,安装到正确的位置。
在使用 RPM 安装软件时,软件名称和其他一些属性被记录到 RPM 数据库中,通常数据库在 /var/lib/rpm 目录。数据库包含了已安装程序的列表,以及属于这些软件的文件,使得以后可以方便地卸载或升级软件。它也记载了文件的属性,包括文件的大小,时间戳,校验和——保证可以在以后检测文件的正确性。数据库也包含了每个程序的依赖性信息,保证管理员安装软件时,所需的软件都已安装,卸载软件时,不会破坏其他现有的程序。
RPM 还包括一些工具。大多数 RPM 管理任务中,最基本的工具是 /bin/rpm 命令。在年代久远的系统中,如果用的是旧版本的 RPM,那么就只有这一个命令。在稍微新一些的系统中,新版本的 RPM 将过去 /bin/rpm 的许多功能移动到了辅助工具中。例如,/usr/bin/rpmbuild 命令用来生成新的 RPM 打包文件,/usr/bin/rpmsign 命令用来签署打包。
/usr/bin/rpm2cpio 命令一直都有,用来将一个 RPM 打包文件转换成标准的归档文件格式。
RPM 还有很多配置文件。在 rhel/fc 中,这些文件在 /etc/rpm 和 /usr/lib/rpm 目录,在 SuSE 中,这些文件只在 /usr/lib/rpm 目录。这些配置文件主要定义了宏——运行 RPM 命令或解析 RPM 打包文件时使用的快捷命令。
Page 5
RPM 打包文件
命名约定 体系结构 格式
要使用 RPM 安装的软件必须打包成 RPM 格式的文件。文件名应当有以下的格式:
名称-版本-发行标记.体系结构.rpm
在这个文件名中,名称表示包含在文件中的软件名,通常是软件的名字。版本表示软件的版本。尽管 RPM 文件格式以及工具没有强制要求,还是应当使用数字来表示版本。在这里使用字母会给很多 RPM 的前端带来问题。
发行标记用来表示对某个版本的打包的修正。有时,在为某个应用程序的某个版本制作 RPM 时会出错。这时,可以制作相同版本的修正了错误的新的 RPM。发行标记用来追踪打包文件的修正。这里也应该是一个数字,并且每次打包被修正后都应递增。
体系结构是这个 RPM 可以安装的系统平台。典型的值可以是:
* i386 任何 32 位 x86 系列 CPU
* i686 任何 686 级别的 32 位 x86 系列 CPU
* ppc64 64 位 PowerPC CPU
* x86_64 AMD 或 Intel 64 位 CPU
* ia64 64 位安腾 CPU
* sparc64 64 位 UltraSparc CPU
除了二进制可执行文件,RPM 还可以用来打包独立于平台的可执行程序 (例如使用解释性语言编写的程序,如 Lips, Perl 或 Java)。如果 RPM 包含的代码可以在任何 CPU 中运行,或者包含文档等独立于平台的文件,那么体系结构通常是 noarch
RPM 打包文件也可以用来打包应用程序源代码,补丁和用来指示如何配置和编译源代码的脚本。这些打包文件的体系结构使用 src,表示它们包含源代码而不是可执行文件。
如果 RPM 用作打包应用程序源代码,但是事实上不包括源代码的原始文件,只在元数据中保留了对源代码的引用,那么体系结构应当使用 nosrc,表示它们实际上没有打包源代码,但是可以像 src.rpm 一样使用。
不考虑它们的名字差别,所有 RPM 打包文件都是一个 cpio 归档文件,附加一个二进制的头部。
Page 6
使用 RPM
安装 升级 删除 查询/校验软件包/文件 rpm -iUFeqV
RPM 打包文件在安装时通常使用 rpm 命令和 -U 参数。通常,还要加上 -v 选项,使得 rpm 输出更多信息,还会加上 -h 选项,使得 rpm 执行时显示进度条
如果想安装一个软件包,同时还保留旧版本 (只有当两个版本中没有相同的文件时才可能做到),那么使用 -i 参数。通常在安装内核时会这样做,为了防止新内核出错,将旧内核保留下来。
也可以用 -F 参数来升级软件包 (通常,还要加上 -v 和 -h 选项),这个参数使得已安装的旧软件包得到更新,但是如果没有安装过,那么就不会安装它。
在进行升级或更新时,rpm 工具比较要安装的 RPM 版本与系统 RPM 数据库中,已安装的版本。如果要安装的软件包版本比已安装的版本更新,那么就升级。如果相反,那么 RPM 拒绝降级。如果版本号相同,RPM 就比较发行标记,只有当新打包的发行标记比已安装的打包的发行标记要新, 才进行升级。
软件包安装之后,可以用 -e 参数来删除
在删除软件包的时候,只要给出软件包的名称。在安装新软件包或者升级时,必须指定打包的全名。
打包文件和已安装的打包都可以查询。rpmquery 命令,或者 rpm 命令加上 -q 参数,都可以做很多查询。类似的,已安装的软件可以用 rpmverify 命令,或者 rpm 命令加上 -V 参数来校验。
Page 7
源代码 RPM 文件
原始源文件 补丁 辅助文件 脚本 .spec
rpm 命令可以用来处理源代码 RPM 文件 (SRPMs)。SRPMs 打包是用来构建作为最终产品安装到系统中的二进制 RPMs 打包的,如 .i386.rpm 和 .noarch.rpm 等等。SRPMs 包含几种不同的文件:
* 程序的最初的源文件
* 任何修改源程序的补丁
* 任何辅助的文件,例如 System V 启动脚本
* 指明如何配置和编译源代码的脚本。脚本通常命名为 name.spec,其中 name 是软件名
RPM 背后的一条设计原则是,软件包应当总是从最初的源代码编译。这一规则对于 Linux 社区很重要,每个程序都是由互联网上的松散的组织开发出来的,然后被 Redhat 和 SuSE 这样的发行版销售商整理到一起,成为一个集成的操作系统。发行版销售商经常需要修改源代码,使之可以更好地集成到发行版中,同样,最终用户也经常需要重新编译,有时需要打补丁,使得销售商提供的应用程序可以更好地适应自己的环境。从最初的源代码开始制作 RPM,加上各自的补丁,有助于简化长期的管理。这也使得最终用户可以容易地发现软件包作出了哪些修改。
通常,支持创建 RPM 的应用程序开发者会发布 SRPMs。不过有些开发者会仅仅发布标准的 Unix tar 打包格式的源代码,在其中包含一个 .spec 文件,指明如何从源代码编译生成一个二进制 RPM。
Page 8
使用源代码 RPMs
重新构建 创建
尽管管理员总是可以找到他们要安装的软件的二进制 RPMs,一些时候他们还是需要编译。有很多从源代码编译的理由:
* 发行版中未包含此软件
* 需要更新软件版本
* 需要以与发行版中的版本不同的选项和特性来编译应用程序
* 需要修正发行版中的版本包含的错误
在从源代码编译时,管理员仍然希望从 RPM 之类的包管理系统中得到便利,包括可以将来轻松地卸载,还有需要的时候升级等等。类似的,管理员在使用 RPM 工具编译时也会得到好处,包括内在的对构建命令的追踪,以及对补丁的取舍。
由于这些原因,管理员会选择从 SRPM 编译生成 RPMs。要生成二进制 RPM,管理员首先需要源代码 RPM,包含了用于生成二进制 RPM 的源代码。管理员通常有两种办法来获得 SRPM:
* 从头创建一个 SRPM
* 使用现有的 SRPM
当使用现有的 SRPM 时,管理员可以原样使用它,也可以进行定制。所有的操作都可以用 RPM 工具完成。
Page 9
准备构建
安装必需的软件 准备非 root 的构建环境
在从 SRPMs 构建 RPMs 的时候,首先需要进行准备工作。编译时需要的软件必须安装在用于构建的机器上。通常,这一需求意味着一般的开发工具,例如 gcc C 编译器以及 make 命令必须安装。与 Linux 发行版的安装方式相关,这些工具可能已经安装了,也可能没有。除了开发工具之外,很多软件包含编译期依赖关系,在编译时必须满足。很多应用程序要求在编译时必须能找到支持库和头文件,如果没有的话必须也安装它们。
二进制文件,一旦被编译,那么就可以在与它被编译的系统中,拥有相同的库文件的系统中顺利执行。因此,最好在与安装的目标系统相同的操作系统中编译它。
在从 SRPMs 构建 RPMs 的时候,尽可能使用非 root 用户,这非常重要。作为 RPM 构建过程的一步,RPM 工具将编译好的软件安装到一个虚拟的文件系统环境中。如果控制 RPM 构建过程的 spec 文件出错,可能导致 RPM 安装到真实的文件系统中。使用非 root 用户构建 RPM,尽管不是总是可行,但是防止了偶然的写入真实文件系统的事故,因为非 root 用户通常对 RPM 在安装时试图写入的目录没有写权限。
在当前的 SuSE 发行版中,RPMs 被配置为支持非 root 用户在 /usr/src/packages 子目录构建 RPM。在 Redhat 发行版中,必须进行配置,才能支持非 root 用户的构建。
要在 Redhat 发行版中配置普通用户构建 RPM:
1. 作为要执行构建的非特权用户登录
2. 创建 RPM 构建所需的目录结构
$ mkdir -p ~/rpmbuild/{BUILD,RPMS,S{OURCE,PEC,RPM}S}
或者
$ cp -a /usr/src/redhat ~/rpmbuild
3. 配置 RPM 在构建时使用新的目录结构,而不是默认的目录结构:
$ echo "%_topdir $HOME/rpmbuild" > ~/.rpmmacros
在执行了这些命令之后,RPM 将会在用户的个人目录下 rpmbuild 目录中构建。要在其他位置构建 RPMs,只要调整路径为合适的值。
Page 10
重构建现有的打包
源代码 RPMs
包含 .spec 文件的 tar 打包
准备好合适的编译环境之后,就可以重建现有的打包了。在较新的系统中,命令:
$ rpmbuild --rebuild name-ver-rel.src.rpm
可以用来编译 SRPMs 生成二进制 RPM,而命令
$ rpmbuild --recompile name-ver-rel.src.rpm
可以用来编译生成未打包的二进制文件。
在过去的系统中,命令分别是 $rpm --rebuild 和 $rpm --recompile
一些开发者以 tar 打包的形式发布源代码,包含了一个 spec 文件。仍然可以用 RPM 来编译这个软件。在较新的系统中,命令:
$ rpmbuild -ta tarball
可以用来编译 tar 打包,生成一个 SRPM 和一个二进制的 RPM。
在过去的系统中,命令是 $rpm -ta。
要安装源代码 RPM,使用这个命令:
$ rpm -Uvh name-ver-rel.src.rpm
这个命令将原始的源代码 tar 打包,补丁还有辅助文件复制到你定义的 SOURCES 目录。spec 文件将复制到你定义的 SPECS 目录。只有当你想在创建二进制 RPM 之前,修改什么的时候,才需要这样做。
Page 11
创建新的 RPMs
准备所需的补丁和辅助文件
创建 .spec 文件
创建和测试 RPM 文件
很多时候,可以找到要编译的软件的 SRPM。但是如果还没有,那么可以用下面的简单的步骤,从头创建一个:
* 准备任何所需的补丁
* 准备任何所需的辅助文件
* 创建 .spec 文件
* 构建并测试 RPM 文件
有些时候,需要用补丁文件来修正已发布的软件。如果要为所编译的软件打补丁,就必须准备它们。
类似的,应用程序需要一些辅助文件才能运行,但是它们不随源代码发布。例如,系统守护进程经常需要一个 System V 初始化脚本,才能在系统启动时运行,但是它们很少提供这个脚本。如果需要这样的文件,必须创建它们。
另外,还必须准备指令,告诉 RPM 如何编译软件。这些指令保存在一个 spec 文件中,在编译 RPM 的时候,RPM 软件将用到它们。
在创建了这些基本的组件之后,就可以构建并测试 RPM 了。通常,这是一个交互的过程——构建过程中,补丁文件以及 spec 文件中的错误必须被捕获并更正,然后重新构建。最后,将得到可行的构建。
将你创建的,并非仅适于你自己的补丁文件,以及 spec 文件提交给软件的作者,这是不错的做法。
Page 12
为软件打补丁
SRPM 包含原始的源代码和补丁 为什么要补丁? 创建补丁
在准备要打包的软件时,通常需要修改软件的源代码。作出修改有很多原因,包括:
* 需要修改硬编码的值,例如软件中的目录路径或者使用限额
* 修正已发布的软件中的错误
* 需要将软件与系统中的其他软件更好地整合
打包者对应用程序的源代码作出的任何修改都应当以补丁文件的形式出现,而不是直接修改原始的源代码。
SRPMs 中总是包括原始的源代码,以及修改源代码所需的补丁文件。这一策略简化了长期的管理,因为它意味着所有本地的修改都保存在各个补丁文件中,可以容易地追踪。它也简化了对源代码可靠性的验证,这在今天木马横行的互联网上非常重要。
创建补丁文件很容易。要创建它,首先将要修改的文件复制一个备份,在原来的名字后面加上一个 .orig 扩展名。接下来,修改需要的地方。接下来,使用 diff 命令加上 -N, -a, -u 和 -r 选项来生成原始文件与修改过的文件的不同之处。最后,将这些不同之处保存为补丁文件。
例如,假设程序 less 需要对源代码中的 edit.c 和 filename.c 做出一些定制。要创建这些修改的补丁文件:
1. 下载并解压源代码
$ tar -zxvf less-378.tar.gz
2. 备份要修改的文件
$ cd less-378
$ cp edit.c edit.c.orig
$ cp filename.c filename.c.orig
3. 修改源代码
$ vi edit.c filename.c
4. 将修改过的不同之处保存到补丁文件中
$ diff -Naur edit.c.orig edit.c > edit.patch
$ diff -Naur filename.c.orig filename.c > filename.patch
这时,生成了两个针对 less 源代码的补丁文件,可以用来创建打过补丁的 less 的 SRPM。
Page 13
创建辅助文件
定时任务 日志轮换 环境设置 特殊情况
很多时候,需要创建辅助文件来正确地运行一个应用程序。很多应用程序需要规律性地定时运行。例如,SquirrelMail 程序创建临时文件,并由定期运行的 tmpwatch 工具删除它。在 Redhat 和 SuSE 发行版中,下列目录被用于执行定时任务:
* /etc/cron.d/
* /etc/cron.hourly/
* /etc/cron.daily/
* /etc/cron.weekly/
* /etc/cron.monthly/
应用程序可以在这些目录中插入 shell 脚本,这些脚本将被每小时,每天,每周或每月执行一次。需要更灵活的定时的程序可以将 crontab 放在 /etc/cron.d/ 目录。在打包需要定时运行某个命令的应用程序时,必须创建合适的文件,放在其中某个目录中。
类似的,一些应用程序需要 shell 或者环境的修改。打包时进行这些修改的 shell 脚本可以放在 /etc/profile.d/ 目录。
会生成日志文件的程序需要保证日志文件可以定期得到轮换,因此应当将一个进行设置的文件放在 /etc/logrotate.d/ 目录中。
需要在系统启动时运行的守护进程需要创建一个初始化脚本。大多数守护进程需要的是一个 System V 启动脚本,而采用超级进程启动的守护进程需要创建的是一个 xinetd 或是 inetd 初始化脚本。
一些程序需要更多配置。基于 X 的应用程序需要向 X 环境中的菜单系统添加条目,因此需要提供一个配置文件,向菜单结构中添加它们。Web 应用程序和 Apache 模块总是需要对 Apache web 服务器的配置进行修改,因此需要配置文件来修改 Apache web 服务器的行为。进行认证的应用程序需要为 PAM 子系统提供配置文件。
Page 14
创建 System V 初始化脚本
独立的守护进程 chkconfig
使用 System V 初始化脚本允许使用标准的方法来管理独立的守护进程,运行:
# /etc/init.d/script name (start|stop|restart)
在为守护进程创建 RPM 的时候,最好创建并安装 SysV 初始化脚本,这样系统管理员可以像管理其他系统自带的守护进程一样,管理它们。
在创建 SysV 初始化脚本的时候,可以基于已有的,简单的脚本,做出必要的修改。在 rhel/fc 中可以参考 /etc/init.d/smartd,在 SLES/SL 中提供了 /etc/init.d/skeleton。
rhel/fc 中,SysV 初始化脚本的官方文档可以在 /usr/share/doc/initscripts-*/sysvinitfiles 文件中找到,而 SLES/SL 中,可以查看 /etc/init.d/README。
chkconfig 命令允许系统管理员容易地控制守护进程应当在哪些运行级启动。例如:
# chkconfig --level 2345 httpd on
要启用这一控制,SysV 初始化脚本的开始必须有特殊的两行,例如:
#!/bin/bash
#
# startup script for the Apache Web Server
#
# chkconfig: 2345 85 15
# description: Apache is a World Wide Web server.
#
首先,chkconfig: 这一行表示,这个守护进程默认应当在运行级 2, 3, 4 还有 5 启动,启动顺序是 85,结束顺序是 15。如果在任何运行级都不应自动启动服务,那么在运行级处使用负号,不要使用数字。这种情况下,安装 RPM 之后,系统管理员可以用
# chkconfig scriptname on
来注册 SysV 初始化脚本。
在 RPM spec 文件中,在 post 安装后脚本部分,应当用这个命令来注册 SysV 初始化脚本:
/sbin/chkconfig --add scriptname
Page 15
创建菜单
freedesktop.org 桌面菜单规约 .desktop 文件
用 RPM 打包应用程序时,最好为它创建一个菜单入口,这样用户可以容易地找到并执行它。
历史上,GNOME 和 KDE 桌面使用自己不同的菜单,菜单文件有不同的格式。发现这个问题后,两个组织走到一起,创建了桌面入口标准。
标准定义了目录 /usr/share/applications/ 为每个菜单入口定义了一个 XML 文件,文件名是 applicationname.desktop
创建了 .desktop 文件之后,可以用 desktop-file-install 命令安装它。这个文件可以用 desktop-file-validate 命令来验证。
对于基本的没有提供描述译文的 .desktop 文件,可以直接在打包的 spec 文件中定义并创建它。
.desktop 文件的完整结构和规则可以在这里找到:
http://standards.freedesktop.org/menu-spec/latest/
spec 文件范例,如何生成和安装 .desktop 文件
%install
......
# 创建菜单入口
cat > %{name}.desktop <<EOF
[Desktop Entry]
Name=BZFlag
Comment=%{summary}
Exec=%{name}
Icon=bzflag-m.xpm
Terminal=0
Type=Application
EOF
mkdir -p %{buildroot}%{_datadir}/applications
desktop-file-install --vendor TimRiker --dir %{buildroot}%{_datadir}/applications --add-category X-Red-Hat-Extra --add-category Application --add-category Game %{name}.desktop
Page 16
.spec 文件
定义元信息 编译 安装 脚本
创建了所需的补丁文件和辅助文件之后,必须创建一个 spec 文件。spec 文件是以一种混合了宏语言、shell 命令以及描述文本的方式书写的。在 spec 文件中,数字符号 (#) 用来表示注释,与绝大多数其他 Unix 配置文件中是一样的。
spec 文件包含几个紧密相关的段落:
* Header 头部
* Prep 准备
* Build 构建
* Install 安装
* Files 文件
* Scripts 脚本
* Changelog 变更记录
总之,这些段落定义了构成应用程序的源文件和补丁,提供了源代码以及应用程序用途的详细信息,指示 RPM 如何编译,定义了 RPM 在安装时需要安装的文件,以及如何安装它们。spec 文件也包含可选的脚本,可以分别在安装过程和卸载过程的前后执行。
Page 17
构建 RPM 过程中涉及到的目录和文件
foo.spec
Summary: The world famous foo
Name: foo
Version: 1.03
Release: 1
License: GPL
Group: Application/System
Source0: foo-%{version}.tar.bz2
Source1: foo.sysinit
Patch0: foo-fix1.patch
Patch1: foo-fix2.patch
BuildRoot: /var/tmp/%{name}-root
%description
This foo daemon serves bar clients.
%prep
%setup -q
%build
%configure
make
%install
rm -rf %{buildroot}
%makeinstall
%clean
rm -rf %{buildroot}
%files
%defattr(-,root,root)
/etc/init.d/foo
%{_sbindir}/foo
/usr/share/man/man8/foo.8
%files devel
%defattr(-,root,root)
/usr/include/foo.h
/usr/lib/foo.a
%changelog
* Mon Apr 30 2003 Dax Kelson
- ver 1.03
1. %prep
* 将文件 (SOURCES/) 解压到构建目录 (BUILD/)
* 打补丁 (SOURCES/ => BUILD/)
2. %build
* 配置 (BUILD/)
* 编译 (BUILD/)
3. %install
* 创建虚拟根文件系统 (/var/tmp/foo-root/)
* 将编译后的二进制文件和相关文件复制到虚拟根分区中的安装位置 (BUILD/ => /var/tmp/foo-root/)
4. %files
* 指定虚拟根分区中,要打包到不同的 RPMs 中的文件 (/var/tmp/foo-root/ => RPMS/i386)
Page 18
使用宏
在 RPM 中大量使用了宏,来进行配置。配置宏可以设置为全局的,只要放在 /usr/lib/rpm/macros 配置文件中。也可以进行个人设置,当 RPM 的任何命令执行时,会查找配置文件 $HOME/.rpmmacros,文件中所定义的任何配置指令将覆盖全局的配置选项。
宏也常常用在 spec 文件中。在 spec 文件中常用的命令都有预先定义的宏,很多系统中常用的目录和路径也有预先定义的宏。
在配置文件和 spec 文件中,为宏名称赋值的方法是,首先写出宏名称,接着写出值。例如,$HOME/.rpmmacros 中下面的语句
%_topdir /export/home/rpmmaker/rpmbuild
将 /export/home/rpmmake/rpmbuild 赋给宏 %_topdir。
在配置文件和 spec 文件中,宏的值可以这样引用,只要将宏名称包含在花括号中就可以了。例如,任何时候宏 %{_topdir} 出现在 spec 文件中时,对于设定了这个宏的用户,它将被自动替换为值 /export/home/rpmmaker/rpmbuild
由于宏在书写 spec 文件时如此有用,很多发行版销售商提供了很多预定义的宏,可以在书写 spec 文件时使用。在 Redhat 发行版中,这些销售商自定义的宏放在 /etc/rpm 子目录。在 SuSE 发行版中,这些销售商自定义的宏放在 /usr/lib/rpm/suse_macros 文件中。另外,/usr/lib/rpm 目录中的配置文件定义了很多标准的宏。在为多种发行版构建打包时,必须小心不要使用销售商自定义的宏。
Page 19
常用的宏
%_prefix /usr
%_exec_prefix %{_prefix}
%_bindir %{_exec_prefix}/bin
%_sbindir %{_exec_prefix}/sbin
%_libexecdir %{_exec_prefix}/libexec
%_datadir %{_prefix}/share
%_sysconfdir %{_prefix}/etc
%_sharedstatedir %{_prefix}/var
%_lib lib
%_libdir %{_exec_prefix}/%{_lib}
%_includedir %{_prefix}/include
%_oldincludedir /usr/include
%_infodir %{_prefix}/info
%_mandir %{_prefix}/man
%configure \
CFLAGS="${CFLAGS:-%optflags}" ; export CFLAGS; \
CXXFLAGS="${CXXFLAGS:-%optflags}" ; export CXXFLAGS; \
FFLAGS="${FFLAGS:-%optflags}" ; export FFLAGS; \
./configure --host=%{_host} --build=%{_build} \\\
--target=%{_target_platform} \\\
--program-prefix=%{?_program_prefix} \\\
--prefix=%{_prefix} \\\
--exec-prefix=%{_exec_prefix} \\\
--bindir=%{_bindir} \\\
--sbindir=%{_sbindir} \\\
--sysconfdir=%{_sysconfdir} \\\
--datadir=%{_datadir} \\\
--includedir=%{_includedir} \\\
--libdir=%{_libdir} \\\
--libexecdir=%{_libexecdir} \\\
--localstatedir=%{_localstatedir} \\\
--sharedstatedir=%{_sharedstatedir} \\\
--mandir=%{_mandir} \\\
--infodir=%{_infodir}
%makeinstall \
make \\\
prefix=%{buildroot}%{_prefix} \\\
exec_prefix=%{buildroot}%{_exec_prefix} \\\
bindir=%{buildroot}%{_bindir} \\\
sbindir=%{buildroot}%{_sbindir} \\\
sysconfdir=%{buildroot}%{_sysconfdir} \\\
datadir=%{buildroot}%{_datadir} \\\
includedir=%{buildroot}%{_includedir} \\\
libdir=%{buildroot}%{_libdir} \\\
libexecdir=%{buildroot}%{_libexecdir} \\\
localstatedir=%{buildroot}%{_localstatedir} \\\
sharedstatedir=%{buildroot}%{_sharedstatedir} \\\
mandir=%{buildroot}%{_mandir} \\\
infodir=%{buildroot}%{_infodir} \\\
install
Page 20
常用的头部字段
Name, Version, Release, License, Group, Source, Patch, URL, Requires, BuildRequires
Head 段落通常是 spec 文件的第一段。它提供了要打包的应用程序的信息。头部的字段包括:
* Name - 应用程序的名称
* Version - 应用程序的版本
* Release - 打包的修订版本
* License - 许可方式 (警告:不要用 Copying 或者 Copyright.)
* Group - 应用程序所属的组
* Source - 应用程序的源代码
* Patch - 应用程序的补丁
* URL - 应用程序原始代码的位置
* Requires - 应用程序运行所必需的软件
* BuildRequires - 编译应用程序时必需的软件
Group 字段有效的取值可以在 Redhat 发行版的 /usr/share/doc/rpm-*/GROUPS 文件中找到。
通常,一个 RPM 会需要多于一个 Source 文件和/或 Patch 文件。这时,Source 和 Patch 字段只要简单地编号:
Source0:
Source1:
Patch0:
Patch1:
Requires 和 BuildRequires 字段是可选的。RPM 会在构建时自动计算软件的依赖性关系。Requires 字段允许开发者列出运行时依赖关系,如果他们需要的话。类似的,BuildRequires 字段用来指定为正确编译,必须安装的软件。尽管不常用,指出任何不明显的构建依赖,警告试图编译软件的人,还是礼貌的做法。Requires 和 BuildRequires 都可以列出它们需要的软件名称,如果需要特定的版本,就列出名称和版本号。
头部通常还有两个字段。Summary 字段用来提供要打包的应用程序的短的,一行的自荐性描述,而 %description 字段提供很长的,可能分为多个段落的描述。
如果要在 spec 文件中创建,定义使用自定义宏,它们通常放在头部。
Page 21
高级的头部字段 Arch, Epoch
特殊情况下会在头部使用其他的字段。很多 Architecture 选项可以用来控制软件包构建的体系结构。BuildArch 用来强制软件包为特定体系结构构建,而不是为构建过程所在的平台的默认体系结构。通常,它用来指示所构建的打包是一个 .noarch.rpm:
BuildArch: noarch
并不是所有软件都能在任何平台中编译,就好像并不是所有软件都能在任何体系结构中运行一样。两个指令可以用来强制这些要求。ExclusiveArch 可以用来列出支持这一软件的平台,在其他平台中 RPM 将不会编译它。ExcludeArch 可以用来列出不支持这一软件的平台,RPM 在其他平台中才会编译它。语句
ExcludeArch: s390 s390x
表示软件应当在除了 31 位和 64 位的 s/390 硬件之外的那些机器上构建,而语句
ExclusiveArch: i386 s390 s390x x86_64
表示软件包应当只在 32 位 x86 硬件,31 位和 64 位 s/390 硬件以及 64 位 AMD (Opteron) 硬件中构建,但不在任何其他系统中构建。
RPM 在头部还提供了 Epoch 字段。通常,RPM 软件使用软件包版本和发行标记来判断一个软件包是否比另一个要新。一些软件使用非标准的版本号,或者改变了版本命名。例如,Postfix MTA 过去使用 YearMonthData 作为版本号 (类似于 postfix-19990906.tar.gz)。最近,Postfix 的作者采用了更为传统的双数位版本命名系统 (类似于 postfix-2.0.9.tar.gz)。在 RPM 比较 19990906 与 2.0.9 的时候,19990906 显然要更新 (版本号更高),尽管实际上它出现四年后,postfix-2.0.9 才发布。要更正这些问题,RPM 使用 Epoch 字段。通常,如果不出现,这个字段被认为是 0,如果需要时可以设置为一个更高的值。当比较版本号时,RPM 首先比较 Epoch,其次是 Version,最后是 Release。因此,Postfix 打包在 Epoch 为 1,Version 为 2.0.9 时,就比 Epoch 为 0,Version 为 19990906 的打包要新了。
Page 22
Prep 段落 准备工作
在 Header 头部之后,下一段落通常是 Prep。这一段落总是以标识 %prep 开始,用来准备要编译的软件。通常,这一段落将归档中的源代码解压,并应用补丁。这些可以用标准的 shell 命令完成,但是更多地使用预定义的宏。
常见的一个宏是 %setup。
这个宏解压源代码,将当前目录改为源代码解压之后产生的目录。这个宏还有一些选项可以用。例如,在解压后,%setup 宏假设产生的目录是
%{name}-%{version}
如果 tar 打包中的目录不是这样命名的,可以用 -n 选项来指定要切换到的目录。例如:
%setup -n %{name}-April2003Rel
另一个 %setup 常用的选项是 -q,它将 tar 命令的繁复输出关闭。
这里常见的另一个宏是 %patch。
这个宏将头部定义的补丁应用于源代码。如果定义了多个补丁,它可以用一个数字的参数来指示应用哪个补丁文件。它也接受 -b extension 参数,指示 RPM 在打补丁之前,将文件备份为扩展名是 extension 的文件。
下面的宏
%patch2 -b .test
指示 RPM 应用 Patch2,将任何要修改的文件备份为扩展名是 .test 的文件。
%patch 宏的 -p 选项控制着要传给 /usr/bin/patch 命令的 -p 选项。通常,会使用 -p1,但是,这当然依赖于补丁文件是如何创建的。
Page 23
构建
在 Prep 段落之后,spec 文件通常包含一个 Build 段落,总是以 %build 标识开始。
在这个段落中,包含用来配置和编译已配置的软件的命令。与 Prep 段落一样,这些命令可以是 shell 命令,也可以是宏。
如果要编译的宏使用了 autoconf,那么应当用 %configure 宏来配置软件。这个宏自动为 autoconf 指定了安装软件的正确选项,编译优化的软件。
如果软件不是用 autoconf 配置的,那么使用合适的 shell 命令来配置它。
软件配置之后,必须编译它。由于各个应用程序的编译方法都各自不同,没有用来编译的宏。只要写出要用来编译的 shell 命令就可以了。
环境变量 $RPM_OPT_FLAGS 在编译软件时很常用。这个 shell 变量包含针对 gcc 编译器套件的正确的优化选项,使用这样的语法:
make CC="gcc $RPM_OPT_FLAGS"
或者
make CFLAGS="$RPM_OPT_FLAGS"
就可以保证总是使用合适的优化选项。也可以使用其他编译器标志和选项。默认的 $RPM_OPT_FLAGS 是:
-O2 -g -march=i386 -mcpu=i686
Page 24
Install 段落
在 Build 段落之后,是 Install 段落。这个段落总是以标记 %install 开始。
这个段落用于将已编译的软件安装到虚拟的目录结构中,从而可以打包成一个 RPM。
在 Header 段落,可以定义 Buildroot,它定义了虚拟目录树的位置,软件将安装到那里。通常,它是这样的:
Buildroot: %{_tmppath}/%{name}-root
或是
Buildroot: %{_tmppath}/%{name}-%{version}-root
使用 RPM 内建的宏来指定 /var/tmp 目录中一个私用的目录。
在 spec 文件的其余部分可以用 shell 变量 $RPM_BUILD_ROOT 获取 Buildroot 的值。
mkdir -p $RPM_BUILD_ROOT/usr/share/icons/
cp %{SOURCE3} $RPM_BUILD_ROOT/usr/share/icons/
Install 段落通常列出要将已编译的软件安装到 Buildroot 中的命令
宏 %makeinstall 可以用于安装支持 autoconf 的软件。这个软件自动地将软件安装到 $RPM_BUILD_ROOT 下的正确的子目录中。
有时,软件包必须被构建多次,由于打包错误或其他原因。每次构建时,Install 段落将复制文件到 Buildroot 中。要防止由于 Buildroot 中的旧文件而导致错误的打包,必须在安装新文件之前将 Buildroot 中任何现有的文件删除。为此,可以使用一个 clean 脚本。这个脚本通常以 %clean 标记表示,通常仅仅包含这样一句:
rm -rf $RPM_BUILD_ROOT
如果有的话,在制作了在 Install 段落中安装的文件的打包之后,将运行 %clean,保证下次构建之前 Buildroot 被清空。
Page 25
Files 段落
在 Install 段落之后,下一个段落是 Files,列出了要打包到一个 RPM 中的文件和目录。这个段落通常以标记 %files 开始。在这个段落中,每行一个,简单地列出文件和目录,相对于 Bduilroot,它们将被存档到打包中。可以在这里使用通配符,例如
/usr/bin/*
指示 RPM 将 $RPM_BUILD_ROOT/usr/bin 目录中所有文件打包。
在列出文件和目录时,必须小心列出所有需要的文件,不要列出任何不应被打包的文件。在列出一个目录时要更加小心。列出一个目录意味着 RPM 要打包这个目录以及其中的所有文件,因此语句
/usr/bin
指示 RPM 将 $RPM_BUILD_ROOT/usr/bin 目录中所有文件打包,但是也会创建一个似乎拥有 /usr/bin 目录的不正确的打包。
在 Files 段落,有一些宏可以用。应当总是应用 %defattr 宏来指定之后列出文件的默认的所有者和权限。例如,语句 %defattr(0770,root,root) 将定义其后列出的所有文件和目录,直到下一个 %defattr 为止,它们在安装后的所有者是 root.root,拥有权限 0770。另外,单独的文件可以用 %attr 指定与 %defattr 不同的所有者和权限。例如:
%files
%defattr(-,root,root)
%{_libdir}/libamanda*.so
%attr(660,amanda,disk) /var/lib/amanda/.amandahosts
一些宏用来指示要安装的文件具有特殊的属性。宏 %dir 可以用来指示要打包的是一个目录,而不是目录中的文件。宏
%config(noreplace)
用来指示被安装的是一个配置文件,在软件包升级时不应被覆盖。
Page 26
可选的脚本段落
有时需要在安装的前后,在系统中运行一些命令。例如,在安装了新的动态链接库之后,应当运行 ldconfig 命令来使系统使用新安装的库。
RPM spec 文件可以包含分别在安装和卸载前后运行的脚本。这些脚本通常在 Files 段落之后列出,是简单的 Bourne shell 脚本,列在一个指示它们何时执行的宏后面。可用的值为:
* %pre - 安装前执行
* %post - 安装后执行
* %preun - 卸载前执行
* %postun - 卸载后执行
最常见的,这些命令用在需要使用新系统帐号才能运行的软件打包中。%pre 脚本可以用来添加需要的帐号,%postun 可以用来在卸载软件时删除这个不再需要的帐号。在 Redhat 系统中准备需要用户帐号的打包时,参考 /usr/share/doc/setup-*/uidgid 文件,它列出了 Redhat 附带的软件已经使用了的 UIDs 和 GIDs。
有时,需要在 %pre, %post, %preun 和 %postun 中执行的脚本是随机的,要根据当前系统中软件的安装情况进行抉择。例如,Mailman 邮件列表管理程序需要一些邮件别名才能工作,因此它的打包需要在 %post 脚本中,向系统添加一些邮件别名,在 %postun 脚本中移除它们。这些别名要写入的位置是随系统中安装的 MTA 而不同的——postfix 使用文件 /etc/postfix/aliases 作为别名数据库,而 Sendmail 使用文件 /etc/aliases 作为别名数据库。
这种情况下,要采用的动作取决于当前系统状态的话,可以用 shell 脚本的条件判断。不过,RPM 提供了一种触发机制,可以用来在其他软件安装/卸载时执行动作。这些脚本以
%triggerin -- package
还有
%triggerun -- package
标记。第一个标记表示软件 package 安装或升级时运行的脚本,而第二个表示软件 package 卸载时运行的脚本。
Page 27
Changelog 段落
spec 中的最终段落是 Changelog 段落。这个段落总是以 %changelog 标记开始,用来列出对打包的任何修改。
尽管日志的结构技术上可以是自由格式,但是大多数 RPM 系统中使用下面的格式:
* 日期 打包人 <打包人的电子邮件> 版本-发行标记
- 所作的更改
- 其他更改
日期必须是下列格式:
Wed Nov 20 2002
这种格式的当前日期可以用命令
date +"%a %b %d %Y"
得到。
每次准备打包的新的修订版时,打包人只要在 Chanlog 段落起始处加上类似的一段。
下列范例是来自 Fedora Core 3 firefox RPM spec:
* Wed Mar 02 2005 Christopher Aillon <[email protected]> 0:1.0.1-1.3.2
- Remerge firefox-1.0-pango-selection.patch
* Thu Feb 24 2005 Christopher Aillon <[email protected]> 0:1.0.1-1.3.1
- Update to 1.0.1 fixing several security flaws.
- Mark some generated files as ghost (#136015)
- Add RPM version to the useragent
- BuildRequires pango-devel
- Enable pango rendering by default
- Enable smooth scrolling by default
Redhat 使用的一个约定是引用它们的错误跟踪系统的错误 Id。在这个例子中,引用了一个有关 RPM 打包的错误。详情可以通过下面的网址查看:
https://bugzilla.redhat.com/bugzilla....cgi?id=136015
Page 28-31
最后的 spec 文件
Page 32
其他内容
除了基本的 spec 文件结构,还有一些高级的需求。通常,一个应用程序需要打包为两个或多个软件包。例如,LessTif 软件包提供了多种不同的内容:一个运行时库,为连接到 Motif 部件集的软件所用,编程的头文件和库文件,开发者用它们来创建应用程序,还有一个窗口管理器。这是三个明显不同的应用程序,不同的用户需要不同的组合。因此, RPM spec 文件可以设定为生成子打包,通过同一个源代码生成两个或多个二进制打包。
另一个常见的需求是在不能获得源代码时,打包二进制文件。例如,Adobe 发布了 Acrobat Reader for Linux,但是在第七版之前,他们只发布二进制可执行文件的 tar 打包。可以为此创建 RPM,允许用户使用 RPM 工具来管理这个程序。要创建这样的 spec 文件,只要简单地省略 Build 段落,在 %install 段落中,手动复制文件到虚拟根文件系统中就可以了。
打包人有时想创建交互式的 RPM,也就是说,在安装过程中询问用户问题。RPM 故意地不支持创建交互的打包!只为保证所有安装过程可以脚本化。要小心设计软件包,避免安装时的交互。
打包人通常需要为多个发行版准备打包。需要考虑一些潜在的复杂情况,才能使单个 spec 文件用于在多个发行版中编译 RPM:
* 不同的发行版预定义了不同的宏。大多数在 Redhat 发行版中定义的宏处于一个 “基线” 上,可以假设绝大多数发行版中也定义了它们,包括 SuSE 发行版。因此,只使用 Redhat 系统中定义的宏,有助于跨发行版的兼容性。
* 不同的发行版使用不同版本的 RPM。旧版本的 Linux 发行版使用旧版本的 RPM 3,而较新的系统使用新的 RPM 4。不同的 RPM 版本中有行为和语法的差别,必须消除。
* 有时不同的发行版将文件安装在不同的位置。Linux Standards Base (LSB) 的努力消除了很多这样的因素,但是还是可能出现。
打包者总会想发布支持多种语言的打包,使用户可以看到以母语显示的打包描述以及相关信息。RPM 提供了一个 specspo 机制,可以用来为打包文件保存已翻译的消息。
Page 33
构建软件包
当准备好 spec 文件之后,接下来是使用 spec 文件构建软件。基本的构建命令,在较新的系统中是 rpmbuild -b spec,在过去的系统中是 rpm -b spec。这个命令支持下面各种不同的参数,取决于要处理 spec 文件的哪一部分:
* -bp - 处理 spec 文件的 Prep 部分
* -bc - 处理 spec 文件的 Prep 和 Build 部分
* -bi - 处理 spec 文件的 Prep, Build 和 Install 部分
* -bl - 校验 spec 文件的 Files 部分
* -bb - 根据 spec 文件构建二进制 RPM
* -bs - 根据 spec 文件构建源代码 RPM
* -ba - 根据 spec 文件同时构建二进制 RPM 和源代码 RPM
最常用的是
rpmbuild -ba spec
有时会用 --target 参数来强制 RPM 为特定的平台编译软件。例如,在 32 位 x86 系统,运行 rhel/fc 的平台中,RPM 默认生成运行在任何 32 位 x86 计算机上的打包,但是对于 80686 级别的计算机会做优化。这个选项可以用来强制 RPM 生成只在 80686 级别的计算机中运行的,或是为 AMD Athlon 更好优化过的,或是为 80386 级别的计算机优化过的打包。命令
rpmbuild -ba --target i686-redhat-linux spec
根据 spec 构建 RPM,只与 80686 级别的机器兼容,比默认的 RPM 优化要稍微更好一点。
在构建打包时,RPM 提供在命令行覆盖或修改 RPM 宏的能力。打包人通常用这个特性来生成可以用来编译相同的软件,但是使用不同选项的 spec。例如,rhel/fc 的 Postfix spec 在 Header 段落包含了各种宏定义,在编译期启用或禁用支持各种特性。这个语句
%define LDAP 0
用来定义 LDAP 的值为 0,在后面 Build 段落中的命令使用这个变量来编译不带 LDAP 支持的 Postfix。使用这样的命令行来覆盖这个变量的值:
rpmbuild -ba --define 'LDAP 1' postfix.spec
Postfix 在编译时就有了 LDAP 支持。
Page 34
数字签名的软件包
由 spec 文件创建了二进制和源代码 RPM 之后,可以使用 GPG 或 PGP 为结果 RPM 签名。签名为下载软件包的最终用户提供了两个重要的功能:
* 它们证明软件包可信,向用户保证,打包来自它应该来自的地方。
* 它们保证打包的完整性,向用户保证软件包在打包人签名之后,没有遭到修改 (尽管 RPM 还通过其他机制提供了这一保证)
这些特性在当今木马横行的互联网上都非常重要。
要签署一个打包,必须首先有一个 GPG 密钥。如果没有的话,可以很容易地生成一个:
$ gpg --gen-key
生成密钥之后,修改你的 RPM macros 来指示 RPM 使用 GPG 签署打包:
echo "%_signature gpg" >> $HOME/.rpmmacros
同时,指定 RPM 应当使用哪个密钥来签署打包:
echo "%_gpg_name 邮件地址" >> $HOME/.rpmmacros
最后,指定 RPM 如何定位你的 GPG 密钥:
echo "%_gpg_path $HOME/.gnupg" >> $HOME/.rpmmacros
配置好 RPM 使用 GPG 之后,可以用 rpmsign 命令来签署你构建的打包:
$ rpmsign --addsign /path/to/the.rpm
可以导出你的公钥:
$ gpg --export --armor > gpg-pub-key
然后将公钥发给安装你的 RPM 的用户,他们可以用它来校验你的 RPM 是由你签署的。要做到这一点,他们必须首先导入你的 GPG 公钥到他们的 RPM GPG 钥匙环中:
# rpmsign --import /path/to/gpg-pub-key
导入公钥之后,可以校验打包的签名了:
$ rpmsign -K package-1.0-1.i386.rpm
package-1.0-1.i386: (sha1) dsa sha1 md5 gpg OK
如果打包通过校验,那么用户就知道它的签名来自他们信任的一方了。
Page 35
修订打包
除创建新的 RPM 之外,打包人另一个经常性的任务是更新现有的打包,在应用程序有新的版本可用时重建打包。修正现有的源代码 RPM 只要很简单的几步:
1. 安装最新的 SRPM
2. 将应用程序的最新的源代码放在 SOURCES 目录
3. 修改 spec 文件为使用最新的源代码
4. 试着做 spec 文件的 Prep 段落:
$ rpmbuild -bp application.spec
在尝试的时候可能会发现,一些补丁不再适用于新版本的源代码了。这时,查看补丁文件的内容,以及应用程序的源代码,检查为什么不适用。
1. 补丁无法应用,是因为不再需要了。这时,只要从 spec 文件中移除补丁就可以了
2. 补丁仍然需要,但是无法应用,因为应用程序的代码在其他部分发生了变化。这时,创建一个新版本的补丁,使它可以适用于新版本的源代码
可以成功完成 Prep 段落之后,更新 spec 文件中的 Changelog 段落以及版本信息,然后构建新打包:
$ rpmbuild -ba application.spec
Page 36
其他资源
有很多资源,提供了更多有关 RPM 和如何创建 RPM 的信息。最好的资源是 http://www.rpm.org ,提供了各种有关 RPM 的文档,以及 RPM 的源代码。这个站点有一本免费下载的书,《Maximum RPM》。尽管它有些过时,但是仍然是不错的补充资源。
很多工具可以简化 RPM 的创建,包括文本编辑器的 spec 文件编辑模式:
http://www.tihlde.hist.no/~stigb/rpm-spec-mode.el
http://pegasus.rutgers.edu/~elflord/vim/syntax/spec.vim
还有各种生成 spec 文件的工具:
http://rpmrebuild.sourceforge.net
http://www.cpan.org/modules/by-modul...le-1.17.tar.gz
http://checkinstall.izto.org
为多个系统准备打包的主要困难是需要有为每个系统准备独立的构建环境。有很多程序可以用来简化在同一台机器上创建多个构建环境:
http://thomas.apesstaart.org/projects/mach
http://www.solucorp.qc.ca/miscprj/s_context.jc
一些网站提供各种高质量的编译好的 RPM,也可以用来寻找已有的 RPM:
http://freshrpms.net
http://www.fedoraproject.org
http://www.rpmfind.net
http://www.GuruLabs.com/downloads.html
有很多工具可以用来简化安装 RPM 的工作,包括:
http://current.tigris.org
http://www.linux.duke.edu/projects/yum
http://www.autorpm.org
http://www.mat.univie.ac.at/~gerald/autoupdate
http://apt4rpm.sourceforge.net
http://www.smartpm.org
实验
任务 1 (6 小题) (p.39-p.42)
任务 2 (10 小题) (p.43-p.51)
任务 3 (53 小题) (p.52-p.79)
任务 4 (13 小题) (p.80-p.86)
作者: bbbush 发布时间: 2005-05-03
作者: fudaming 发布时间: 2005-05-03
作者: iisraul 发布时间: 2005-05-03
这里还有一些非常有用的文档,可以学习 rpm 系统的使用
http://www.rpm.org/rpmapi-4.1/pages.html
rpm Related Pages Here is a list of all related documentation pages: * Default configuration: /usr/lib/rpm/macros http://www.rpm.org/rpmapi-4.1/config_macros.html * Default configuration: /usr/lib/rpm/rpmpopt-4.1 http://www.rpm.org/rpmapi-4.1/config_rpmpopt.html * Default configuration: /usr/lib/rpm/rpmrc http://www.rpm.org/rpmapi-4.1/config_rpmrc.html * Generating buiild dependencies automatically http://www.rpm.org/rpmapi-4.1/builddpendencies.html * Using a build root http://www.rpm.org/rpmapi-4.1/buildroot.html * Passing conditional parameters into a rpm build http://www.rpm.org/rpmapi-4.1/conditionalbulds.html * Dependencies http://www.rpm.org/rpmapi-4.1/dependencies.html * Package format http://www.rpm.org/rpmapi-4.1/pkgformat.html * Immutable header regions in rpm-4.0.1 and later http://www.rpm.org/rpmapi-4.1/hregions.html * Macro syntax http://www.rpm.org/rpmapi-4.1/macros.html * Multiple build areas http://www.rpm.org/rpmapi-4.1/multiplebuilds.html * Query formats http://www.rpm.org/rpmapi-4.1/queryformat.html * Signature header http://www.rpm.org/rpmapi-4.1/signatures.html * Relocateable packages http://www.rpm.org/rpmapi-4.1/relocateable.html * Spec file tags http://www.rpm.org/rpmapi-4.1/specfile.html * Trigger scriptlets http://www.rpm.org/rpmapi-4.1/triggers.html * Package ordering in rpm-4.0.1 and later http://www.rpm.org/rpmapi-4.1/tsort.html * Todo List Generated at Thu Apr 19 15:29:51 2001 for rpm by doxygen |
作者: bbbush 发布时间: 2005-05-03
作者: narsil 发布时间: 2005-05-04
fedora-extras 仓库
fedora-rpmdevtools 软件包
fedora-buildrpmtree 命令
作用:构造非 root 用户的 rpm 目录树,并且设置在个人目录中进行 rpm 打包的宏
作者: bbbush 发布时间: 2005-05-07
gendiff.1
GENDIFF(1) GENDIFF(1) NAME gendiff - 致力于创建无错的 diff 文件的工具 SYNOPSIS gendiff <directory> <diff-extension> DESCRIPTION gendiff 是一个简单的脚本,目标是根据单一的目录生成一个 diff 文件。它以 一个目录名,以及一个 "diff 扩展名" 作为它的参数。diff 扩展名应当是一 个 唯 一 的 字符序列,添加到所有原始的,未修改的文件后面。程序的输出是一个 diff 文件,可以使用 patch 程序来应用它,重新创造修改。 通常,创建 diff 文件的步骤是创建两个完全相同的目录,在其中一个中进行 修 改,然后使用 diff 工具来创建两个目录之间区别的列表。使用 gendiff 消除了 对额外的,原始的,未修改的目录复件的要求。只有需要修改的个别文件需要 被 保存。 在 编辑之前,复制一份文件,将所选的扩展名附加到文件名后面。也就是说,如 果要修改 somfile.cpp,并且已经选择了扩展名 "fix",那么在修改之前,将 它 复制为 somefile.cpp.fix。然后,修改原来的文件 (somefile.cpp)。 这样编辑所有文件之后,进入源代码所在的那个目录的上级目录,然后输入 $ gendiff somedirectory .fix > mydiff-fix.patch 应当将输出重定向到一个文件 (像例子中一样),除非你想在标准输出上看到结果 。 SEE ALSO diff(1), patch(1) AUTHOR Marc Ewing <[email protected]> TRANSBY LinuxForum.Net CMPP 中文手册页计划 [url=http://cmpp.linuxforum.net] * Tue May 3 2005 Yuan Yijun <[email protected]> rpm-4.4.1-3 - 初始版本, 来自于 rpm 的手册页集合 4th Berkeley Distribution Mon Jan 10 2000 GENDIFF(1)
rpm2cpio(8) Red Hat Linux rpm2cpio(8) NAME rpm2cpio - 从 RPM 软件包中提取 cpio 归档 SYNOPSIS rpm2cpio [filename] DESCRIPTION rpm2cpio 将指定的一个 .rpm 文件转换为一个 cpio 文档,输出到标准输出。如 果给出了 ‘-’ 参数,那么将从标准输入读取 rpm 文件。 rpm2cpio rpm-1.1-1.i386.rpm rpm2cpio - < glint-1.0-1.i386.rpm SEE ALSO rpm(8) AUTHOR Erik Troan <[email protected]> TRANSBY LinuxForum.Net CMPP 中文手册页计划 [url=http://cmpp.linuxforum.net] * Tue May 3 2005 Yuan Yijun <[email protected]> rpm-4.4.1-3 - 初始版本, 来自于 rpm 的手册页集合 Red Hat, Inc. 11 January 2001 rpm2cpio(8)
RPMCACHE(8) Red Hat Linux RPMCACHE(8) NAME rpmcache - 缓存 RPM 打包头部 SYNOPSIS rpmcache [ PACKAGE_NAME ... ] DESCRIPTION rpmcache 遍历文件树,可能通过 FTP 使用远程文件,使用 glob(7) 表达式过滤 路径,读取 rpm 打包头部。最新的软件包 (对于相同的软件包名称,比较代/ 版 本/ 发 行数字,以及构建时间,来解决冲突) 的头部,如果唯一的话,就缓存在 rpm 数据库中。rpm 数据库缓存可以用来提供解决软件包未知依赖关系时的建 议 。 没有特定于 rpmcache 的选项,只有一般的 rpm 选项。参见 rpmcache 用法信息 ,察看当前已实现的内容。 要搜索的文件树路径是以 rpm 宏配置的。最终路径是 5 个独立的元素的拼装 。 下面是用于配置 rpmcache 的宏名称。在文件树中将遍历: %_bhpath " 路径" 一级包含要遍历的文件树的文件树路径 (或 URL) 的前缀部分。 这里不能使用 glob(7) 表达式。 %_bhcoll "集合" 一级包含一个字符串 (或 glob(7) 表达式),来匹 配 %_bhpath 的子目录。 %_bhN " 名 称" 一级包含一个字符串 (或 glob(7) 表达式),来匹配 %_bhcoll 的子目录。可以用 PACKAGE_NAME 参数来构造一个 glob(7) 表达式, 匹 配 Redhat 构建系统中任何指定软件包的名称,在 Redhat 之外几乎没有 任何用处。 %_bhVR "版本发行" 一级包含一个字符串 (或 glob(7) 表达式),来匹配 %_bhN 的子目录。 %_bhA "体系结构" 一级包含一个字符串 (或 glob(7) 表达式),来匹配 %_bhVR 的子目录。 缓存数据库的位置也使用一个 rpm 宏 %_cache_dbpath 来配置。默认的值是 /var/spool/up2date/cache。 缓存数据库与 rpm 数据库的格式完全相同,可以用在 rpm 命令中。例如,要 使 用 缓存数据库,来提供建议,给出满足软件包安装时依赖关系的软件包,可以将 下面的宏配置在 /etc/rpm/macros 或 ~/.rpmmacros 中: %_solve_dbpath 用于提供依赖关系建议的数据库的位置 范例 (最小) 配置,针对一个 Redhat 文件树: %_cache_dbpath /var/spool/up2date/cache %_solve_dbpath %{_cache_dbpath} %_bhpath file://localhost/mnt/redhat/beehive/comps/dist %_bhcoll 7.3 %_bhN @(basesystem|bash|filesystem|glibc-common|glibc|ldconfig|libtermcap|mktemp|setup|termcap) %_bhVR * %_bhA @(i[3456]86|noarch) 范例 (最小) 配置,针对一个 Redhat FTP 树: %_cache_dbpath /var/spool/up2date/cache %_solve_dbpath %{_cache_dbpath} %_bhpath ftp://localhost/mnt/dist %_bhcoll @(7.3|7.2|7.1|7.0|6.2|6.1|6.0|5.2|5.1|5.0) %_bhN @(%{_arch}) %_bhVR * %_bhA @(i[3456]86|noarch) BUGS Yup. 请将有关 rpm-devel 软件包的错误报告和特性需求提 交 到 bugzilla : http://bugzilla.redhat.com/ <URL:http://bugzilla.redhat.com/> SEE ALSO rpm(8), glob(7), http://www.rpm.org/ <URL:http://www.rpm.org/> AUTHORS Jeff Johnson <[email protected]> TRANSBY LinuxForum.Net CMPP 中文手册页计划 [url=http://cmpp.linuxforum.net] * Tue May 3 2005 Yuan Yijun <[email protected]> rpm-4.4.1-3 - 初始版本, 来自于 rpm 的手册页集合 Red Hat, Inc. 05 July 2002 RPMCACHE(8)
RPMDEPS(8) Red Hat Linux RPMDEPS(8) NAME rpmdeps - 生成 RPM 软件包依赖关系 SYNOPSIS rpmdeps {-P|--provides} {-R|--requires} FILE ... DESCRIPTION rpmdeps 根据 FILE 参数集合,生成软件包依赖关系。FILE 参数中的每个都进行 搜索,查找 Elf32/Elf64,脚本解释器,以及每个脚本的依赖性关系,将依赖 性 关系输出到标准输出。 SEE ALSO rpm(8), rpmbuild(8), AUTHORS Jeff Johnson <[email protected]> TRANSBY LinuxForum.Net CMPP 中文手册页计划 [url=http://cmpp.linuxforum.net] * Tue May 3 2005 Yuan Yijun <[email protected]> rpm-4.4.1-3 - 初始版本, 来自于 rpm 的手册页集合 Red Hat, Inc. 24 October 2002 RPMDEPS(8)
RPMGRAPH(8) Red Hat Linux RPMGRAPH(8) NAME rpmgraph - 显示 RPM 软件包依赖关系图 SYNOPSIS rpmgraph PACKAGE_FILE ... DESCRIPTION rpmgraph 使用 PACKAGE_FILE 参数来产生一个软件包依赖关系图。每个 PACK- AGE_FILE 参数都被读取并添加到 rpm 事务集中。事务集的元素使用拓扑排序 得 到偏序关系。元素的偏序关系被输出到标准输出。 依 赖关系图中的节点是软件包名称,有向图中的边指向每个节点的父节点。父节 点被定义为,将软件包依赖性作为一个偏序关系,一个软件包的最近的前驱。 这 意味着,给定一个软件包,它的父节点是它依赖的软件包中的最后一个。 输出是 dot(1) 有向图格式,可以使用 graphviz 软件包中的 dotty 图像编辑器 来显示或打印。没有特定于 rpmgraph 的选项,只有一般的 rpm 选 项 。 参 见 rpmgraph 用法信息,察看当前已实现的内容。 SEE ALSO dot(1), dotty(1), http://www.graphviz.org/ <URL:http://www.graphviz.org/> AUTHORS Jeff Johnson <[email protected]> TRANSBY LinuxForum.Net CMPP 中文手册页计划 [url=http://cmpp.linuxforum.net] * Tue May 3 2005 Yuan Yijun <[email protected]> rpm-4.4.1-3 - 初始版本, 来自于 rpm 的手册页集合 Red Hat, Inc. 30 June 2002 RPMGRAPH(8)
RPM(8) Red Hat Linux RPM(8) NAME rpm - RPM 软件包管理器 SYNOPSIS 查询和校验软件包: rpm {-q|--query} [select-options] [query-options] rpm {-V|--verify} [select-options] [verify-options] rpm --import PUBKEY ... rpm {-K|--checksig} [--nosignature] [--nodigest] PACKAGE_FILE ... 安装,升级和卸载软件包: rpm {-i|--install} [install-options] PACKAGE_FILE ... rpm {-U|--upgrade} [install-options] PACKAGE_FILE ... rpm {-F|--freshen} [install-options] PACKAGE_FILE ... rpm {-e|--erase} [--allmatches] [--nodeps] [--noscripts] [--notriggers] [--repackage] [--test] PACKAGE_NAME ... 其他: rpm {--initdb|--rebuilddb} rpm {--addsign|--resign} PACKAGE_FILE ... rpm {--querytags|--showrc} rpm {--setperms|--setugids} PACKAGE_NAME ... 选择选项 [PACKAGE_NAME] [-a,--all] [-f,--file FILE] [-g,--group GROUP] {-p,--package PACKAGE_FILE] [--fileid MD5] [--hdrid SHA1] [--pkgid MD5] [--tid TID] [--querybynumber HDRNUM] [--triggeredby PACKAGE_NAME] [--whatprovides CAPABILITY] [--whatrequires CAPABILITY] 查询选项 [--changelog] [-c,--configfiles] [-d,--docfiles] [--dump] [--filesbypkg] [-i,--info] [--last] [-l,--list] [--provides] [--qf,--queryformat QUERYFMT] [-R,--requires] [--scripts] [-s,--state] [--triggers,--triggerscripts] 校验选项 [--nodeps] [--nofiles] [--noscripts] [--nodigest] [--nosignature] [--nolinkto] [--nomd5] [--nosize] [--nouser] [--nogroup] [--nomtime] [--nomode] [--nordev] 安装选项 [--aid] [--allfiles] [--badreloc] [--excludepath OLDPATH] [--excludedocs] [--force] [-h,--hash] [--ignoresize] [--ignorearch] [--ignoreos] [--includedocs] [--justdb] [--nodeps] [--nodigest] [--nosignature] [--nosuggest] [--noorder] [--noscripts] [--notriggers] [--oldpackage] [--percent] [--prefix NEWPATH] [--relocate OLDPATH=NEWPATH] [--repackage] [--replacefiles] [--replacepkgs] [--test] DESCRIPTION rpm 是一个强大的 软件包管理器,可以用来构建,安装,查询,校验,升级和卸 载单独的软件打包。一个 打包 包括文件的归档,以及用来安装和卸载归档文 件 的元信息。元信息包括辅助脚本,文件属性以及打包的描述性信息。打包 有两种 ,二进制打包,用来封装要安装的软件;源代码打包,包含源代码以及为生成 二 进制打包,必要的文件。 必 须选择下列模式之一: Query 查询, Verify 校验, Signature Check 检查签 名, Install/Upgrade/Freshen 安装/升级/更新, Uninstall 卸载, Initialize Database 初始化数据库, Rebuild Database 重构数据库, Resign 重签名, Add Signature 添加签名, Set Owners/Groups 设置属主, Show Querytags 显示查询 标记, 以及 Show Configuration 显示配置. 一般选项 这些选项可以用在所有不同的模式中。 -?, --help 输出更长的帮助信息。 --version 输出一行信息,包括使用的 rpm 的版本号。 --quiet 输出尽可能少的信息 - 通常只有错误会显示。 -v 输出冗余信息 - 通常,常规的进度信息将显示。 -vv 输出大量丑陋的调试信息。 --rcfile FILELIST FILELIST 中冒号分隔的每个文件名都被 rpm 按顺序读取,从中获得配置 信息。只有列表的第一个文件必须存在,波浪线将被替换为 $HOME。默认 的 FILELIST 是 /usr/lib/rpm/rpmrc:/usr/lib/rpm/red- hat/rpmrc:/etc/rpmrc:~/.rpmrc --pipe CMD 将 rpm 的输出通过管道送到命令 CMD。 --dbpath DIRECTORY 使用 DIRECTORY 中的数据库,而不是默认的路径 /var/lib/rpm --root DIRECTORY 以 DIRECTORY 作为根文件系统,进行所有操作。这意味着将使用 DIREC- TORY 中 的 数 据库来进行依赖性检测,任何小程序 (也就是安装中的 %post 和构建中的 %prep) 都将在一个 chroot(2) 到 DIRECTORY 之后执 行。 安装和升级选项 安装命令的一般形式是 rpm {-i|--install} [install-options] PACKAGE_FILE ... 这样安装了一个新软件包。 升级命令的一般形式是 rpm {-U|--upgrade} [install-options] PACKAGE_FILE ... 这 样安装或升级已安装的软件包到新版本。它与安装类似,只是所有其他版本的 打包在新软件包安装后都将移除。 rpm {-F|--freshen} [install-options] PACKAGE_FILE ... 仅当系统中存在更早的版本时,这样会升级软件包。PACKAGE_FILE 必须指 定 为 ftp 或 http URL,这样软件包可以在安装之前去下载。参见 FTP/HTTP OPTIONS 中有关 rpm 的内嵌 ftp 和 http 客户端支持。 --aid 需要时将建议的软件包加入事务集。 --allfiles 安装或升级软件包中所有 missingok 文件,哪怕它们已经存在。 --badreloc 与 --relocate 搭配使用,允许所有文件的重定位,而不仅仅是在二进制 打包中,重定位提示包含的那些 OLDPATH。 --excludepath OLDPATH 不安装名称以 OLDPATH 开始的文件。 --excludedocs 不安装任何标记为文档的文件 (包括手册页和 texinfo)。 --force 与使用 --replacepkgs, --replacefiles, 以及 --oldpackage 相同。 -h, --hash 在打包被解压时,输出 50 个 hash 符号 (#),用来与 -v|--verbose 配 合,得到漂亮一点的输出。 --ignoresize 安装前不检测已挂载文件系统的空闲空间。 --ignorearch 允许安装或升级,即使二进制打包的体系结构与主机不匹配。 --ignoreos 允许安装或升级,即使二进制打包的操作系统与主机不匹配。 --includedocs 安装文档文件。这是默认的行为。 --justdb 只更新数据库,不更新文件系统。 --nodigest 读取时不校验打包或头部校验。 --nosignature 读取时不校验打包或头部签名。 --nodeps 在安装或升级前,不进行依赖性检测。 --nosuggest 不建议提供了所需依赖关系的软件包。 --noorder 不为安装重排序。通常软件包列表会被重排序,以满足依赖性关系。 --noscripts --nopre --nopost --nopreun --nopostun 不执行对应的小程序。--noscripts 选项与 --nopre --nopost --nopreun --nopostun 等价,将 %pre, %post, %preun, 和 %postun 小程序全部关闭。 --notriggers --notriggerin --notriggerun --notriggerpostun 不执行任何对应的触发小程序。--notriggers 选项与 --notriggerin --notriggerun --notriggerpostun 等价,将 %triggerin, %triggerun, 和 %triggerpostun 小程序全部 关 闭。 --oldpackage 允许用旧软件包替换一个新软件包。 --percent 打 印从软件包中解压文件的百分比。这是为了使 rpm 在其他工具中运行 时简单一些。 --prefix NEWPATH 对于可重定位的包,将以软件包重定位提示的安装前缀开始的所有文件路 径转换为以 NEWPATH 开始。 --relocate OLDPATH=NEWPATH 对 于克重定位的二进制打包,将软件包重定位提示中,以 OLDPATH 开始 的文件路径转换为以 NEWPATH 开始。这一选项可以使用多次,如果软 件 包中多个 OLDPATH 要重定位的话。 --repackage 在 卸 载 前 重 新 打 包 文 件 。过去安装的打包将根据宏 %_repack- age_name_fmt 命名,将创建于宏 %_repackage_dir 指定的目录中 (默认 值是 /var/spool/repackage)。 --replacefiles 安装软件包,即使他们替换了其他已安装的软件包的文件。 --replacepkgs 安装软件包,即使其中有些软件包已经被安装到了系统中。 --test 不安装软件包,仅仅检测并报告可能的冲突。 卸载选项 卸载命令的一般形式是 rpm {-e|--erase} [--allmatches] [--nodeps] [--noscripts] [--notriggers] [--repackage] [--test] PACKAGE_NAME ... 同时还可以用下列选项: --allmatches 删除匹配 PACKAGE_NAME 的软件包的所有版本。通常情况下,如果 PACK- AGE_NAME 匹配多个软件包将导致错误。 --nodeps 在卸载前不检测依赖关系。 --noscripts --nopreun --nopostun 不执行相应的小程序。--noscripts 选项在卸载过程中等价于 --nopreun --nopostun 将 %preun, 和 %postun 小程序的执行关闭。 --notriggers --notriggerun --notriggerpostun 不执行相应的触发小程序。--notriggers 选项等价于 --notriggerun --notriggerpostun 将 %triggerun, 和 %triggerpostun 小程序的执行关闭。 --repackage 卸 载 前 重 新 打 包 文 件 。 过去安装的软件包将根据宏 %_repack- age_name_fmt 命名,存放到宏 %_repackage_dir 定义的目录中 (默认值 是 /var/spool/repackage)。 --test 不真正卸载任何东西,仅仅尝试它们。与 -vv 选项联合使用,在调试时 很有用。 查询选项 查询命令的一般形式是 rpm {-q|--query} [select-options] [query-options] 可以指定输出时软件包信息的格式。为此,使用选项 --qf|--queryformat QUERYFMT 附带 QUERYFMT 格式化字符串。查询命令是标准的 printf(3) 格式的修改版本。 格式包括静态字符串 (可能包括标准的 C 转义字符,新行符,跳格以及其他特殊 字符) 以及 printf(3) 类型标记。由于 rpm 已知输出类型,因此应当忽略类 型 标 记,使用头部字段名来代替,包含在 {} 中。字段名是大小写不敏感的,起始 的 RPMTAG_ 部分可以被忽略。 可选的输出格式是用 :typetag 表示。当前,支持的类型有: :armor 将公钥以 ASCII 包装。 :base64 以 base64 编码二进制数据。 :date 使用 strftime(3) "%c" 格式。 :day 使用 strftime(3) "%a %b %d %Y" 格式。 :depflags 格式化依赖性标志。 :fflags 格式化文件标志。 :hex 以十六进制格式化。 :octal 以八进制格式化。 :perms 格式化文件权限。 :shescape 转义单引号,用于脚本。 :triggertype 显示触发的后缀。 例如,要只输出所查询的软件包的名称,可以使用 %{NAME} 作为格式化字符串。 要 分两列输出软件包名称和发行版信息,可以用 %-30{NAME}%{DISTRIBUTION}。 如果执行时使用 --querytags 参数,rpm 将输出它已知的所有标记列表。 查询的选项有两个子集:软件包选择和信息选择。 软件包选择选项: PACKAGE_NAME 查询名称为 PACKAGE_NAME 的已安装软件包。 -a, --all 查询所有已安装软件包。 -f, --file FILE 查询包含 FILE 的软件包。 --fileid MD5 查询包含给定文件描述字的软件包,例如,文件内容的 MD5 校验和。 -g, --group GROUP 查询属主为 GROUP 的软件包。 --hdrid SHA1 查询包含给定头部描述字的软件包,例如,不可变头部区域的 SHA1 校验 和。 -p, --package PACKAGE_FILE 查 询 (未安装的) 软件包 PACKAGE_FILE。这个文件可以指定为一个 ftp 或 http 样式的 URL,这时软件包头部将被下载并查询。参见 FTP/HTTP OPTIONS 中有关 rpm 的内部 ftp 和 http 客户端支持信息。参数 PACK- AGE_FILE 如果不是一个二进制文件,将被解释为一个 ASCII 软件包说明 。 其中可以有以 ’#’ 开始的注释,其他的每行都可以包含以空格分隔的 匹配表达式,如果是远程的地址,也包括 URL。这些将被扩展为路径,替 换 manifest 参数的位置,作为 PACKAGE_FILE 参数的附加查询内容。 --pkgid MD5 查 询 含有给定软件包描述字的软件包,例如,包的头部以及有效内容的 MD5 校验和。 --querybynumber HDRNUM 直接查询第 HDRNUM 个数据库入口;这只在调试时有用。 --specfile SPECFILE 解释并查询 SPECFILE,就好像它是一个软件包。尽管并非所有信息都 可 获 得,但这种查询允许 rpm 从 spec 文件中抽取信息,而不必写一个解 释器。 --tid TID 查询包含给定 TID 事务描述字的软件包。当前使用 unix 时间戳作为 事 务描述字。任何在一次事务中安装或卸载的软件包拥有相同的描述字。 --triggeredby PACKAGE_NAME 查询被软件包 PACKAGE_NAME 触发的软件包。 --whatprovides CAPABILITY 查询提供了 CAPABILITY 能力的软件包。 --whatrequires CAPABILITY 查询所有需要 CAPABILITY 才能运作的软件包。 软件包查询选项: --changelog 显示软件包的修改信息。 -c, --configfiles 只显示配置文件 (暗含了 -l). -d, --docfiles 只显示文档文件 (暗含了 -l). --dump 转储文件信息: path size mtime md5sum mode owner group isconfig isdoc rdev symlink 这个选项必须与至少下列之一联合使用 -l, -c, -d. --filesbypkg 列出所选每个软件包中的文件。 -i, --info 显 示 软件包信息,包括名称,版本,描述。如果指定了 --queryformat 就使用它。 --last 列出软件包时,以安装时间排序,最新的在上面。 -l, --list 列出软件包中的文件。 --provides 列出软件包提供的特性。 -R, --requires 列出软件包依赖的其他软件包。 --scripts 列出软件包自定义的小程序,他们是安装和卸载等等过程的一部分。 -s, --state 显示软件包中文件的状态 states (暗含了 -l)。每个文件的状态是 nor- mal, not installed, 或 replaced 其中之一。 --triggers, --triggerscripts 显示软件包中包含的触发脚本,如果有的话。 校验选项 校验命令的一般形式是 rpm {-V|--verify} [select-options] [verify-options] 校验软件包,是将已安装的文件的信息,与从软件包中获取的保存在 rpm 数据库 中的有关文件的元数据进行比较。校验比较的内容有每个文件的大小,MD5 校 验 和 ,许可,类型,属主。任何不对的地方都回显示出来。如果软件包中文件未安 装,例如在安装过程中使用 "--excludedocs" 选项跳过的文档,将被跳过。 软件包选择选项与软件包查询是相同的 (包括以说明文件作为参数)。其他独有的 选项包括: --nodeps 不校验软件包的依赖关系。 --nodigest 读取时不校验软件包或头部校验。 --nofiles 不校验文件的任何属性。 --noscripts 不执行 %verifyscript 小程序,如果有的话。 --nosignature 读取时不校验软件包或头部签名。 --nolinkto --nomd5 --nosize --nouser --nogroup --nomtime --nomode --nordev 不校验相应的文件属性。 输出是 8 个字符的字符串,可能的属性标记为: c %config 配置文件 d %doc 文档 g %ghost 占位文档 (就是说,文件内容不包含在软件包有效内容里面) l %license 许可文件 r %readme 说明文件 从头部开始,接下来是文件名,每 8 个字符表示将文件属性与数据库中记录的值 进行一次比较的结果。一个单独的 "." (句点) 表示测试通过了,而一个单独 的 "?" (问号) 表示测试可能无法进行 (例如,文件许可禁止了读权限)。最后,加 重的字母表示相应的 --verify 测试失败了。 S file Size 大小不一致 M Mode 模式不一致 (包括许可和文件类型) 5 MD5 sum 校验和不一致 D Device 主从设备号不匹配 L readLink(2) 路径不匹配 U User 属主不一致 G Group 组属主不一致 T mTime 时间不一致 数字签名和校验 数字签名命令的一般形式是 rpm --import PUBKEY ... rpm {--checksig} [--nosignature] [--nodigest] PACKAGE_FILE ... 选项 --checksig 用来检测 PACKAGE_FILE 中所有的签名和摘要,保证打包的 完 整 性和来源。注意在读取打包时总会检测签名,而 --checksig 在校验与某个打 包关联的所有签名和摘要时有用。 没有公钥就无法校验数字签名。可以用 --import 来向 rpm 数据库添 加 ASCII 文 本化的公钥。每个导入的公钥都有一个头部,钥匙环的管理与软件包管理完全 类似。例如,要显示所有已导入的公钥,使用: rpm -qa gpg-pubkey* 已导入的公钥的细节,可以查询并显示。下面是有关 Redhat GPG/DSA 公钥的 信 息: rpm -qi gpg-pubkey-db42a60e 最后,已导入的公钥可以像软件包一样被删除。下面是如何卸载 Redhat GPG/DSA 公钥: rpm -e gpg-pubkey-db42a60e 签署软件包 rpm --addsign|--resign PACKAGE_FILE ... 选项 --addsign 与 --resign 都可以为每个软件包 PACKAGE_FILE 生成并插入新 的 签名,替换任何已有的签名。存在两个选项,是由于历史的原因,现在它们的 行为没有区别。 使用 GPG 来签署软件包 为使用 GPG 来签署软件包,必须配置 rpm 运行 GPG,并且要能找到包含合适 密 钥 的 钥匙环。默认情况下,rpm 使用与 GPG 相同的约定来查找钥匙环,也就是 $GNUPGHOME 环境变量。如果你的钥匙环不在 GPG 要求的位置,就必须 配 置 宏 %_gpg_path 为要使用的 GPG 钥匙环的位置。 为了与老版本的 GPG, PGP 和 rpm 兼容,只应配置 V3 OpenPGP 签名的打包。可 以使用 DSA 或者 RSA 校验算法,但是推荐用 DSA。 如果想签署自己创建的打包,还需要创建自己的公钥和私钥对 (参见 GPG 手 册) 。还需要配置 rpm 宏: %_signature 签名类型。当前只支持 gpg 和 pgp。 %_gpg_name 用来签署打包的密钥的所有者 "用户" 的名称 例如,要使用 GPG 来签署打包,用户是 "John Doe <[email protected]>",钥匙环位 置在 /etc/rpm/.gpg,使用可执行文件 /usr/bin/gpg,可以将这一段 %_signature gpg %_gpg_path /etc/rpm/.gpg %_gpg_name John Doe <[email protected]> %_gpgbin /usr/bin/gpg 包含在宏配置文件中。对于系统范围的设置,使用 /etc/rpm/macros,对于个 人 设置,使用 ~/.rpmmacros。 重建数据库选项 重建数据库的命令的一般形式是 rpm {--initdb|--rebuilddb} [-v] [--dbpath DIRECTORY] [--root DIRECTORY] 使用 --initdb 来创建新的数据库,使用 --rebuilddb 来重建数据库索引,根据 已安装的软件包头部。 显示配置 命令 rpm --showrc 将显示 rpm 使用的,在 rpmrc 和 macros 配置文件中定义的选项的值。 FTP/HTTP 选项 rpm 可以作为一个 FTP 和/或 HTTP 客户端,可以查询或安装互联网上的软件包 包。要安装、升级和查询的软件包文件可以以 ftp 或 http 样式的 URL 指定: ftp://USER:PASSWORD@HOST:PORT/path/to/package.rpm 如果忽略了 :PASSWORD 选项,将提示密码,每个用户名/主机组合提示一次。 如 果 忽 略 了用户名和密码,将使用匿名 ftp。在所有情况下,都会使用被动 ftp (PSAV)。 rpm 允许在使用 ftp URL 时使用下面的选项: --ftpproxy HOST 使用主机 HOST 作为所有 ftp 传输的**服务器,允许用户通过** 系 统防火墙访问 ftp。这个选项也可以用宏 %_ftpproxy 指定。 --ftpport PORT 连 接到 ftp **服务器的 TCP PORT 端口,而不是默认的端口。这个选 项也可以用宏 %_ftpport 指定。 rpm 允许在使用 http URL 时使用下面的选项: --httpproxy HOST 使用主机 HOST 作为所有 http 传输的**服务器,允许用户通过**系 统防火墙访问 http。这个选项也可以用宏 %_httpproxy 指定。 --httpport PORT 连接到 http **服务器的 TCP PORT 端口,而不是默认的端口。这个选 项也可以用宏 %_httpport 指定。 LEGACY ISSUES 执行 rpmbuild rpm 的构建模式,现在由 /usr/bin/rpmbuild 命令完成。尽管使用下面的 popt 别 名提供的兼容性已经够用,但是不够完美;因此通过 popt 别名提供的构建兼 容性将从 rpm 中移除。安装 rpmbuild 软件包,参见 rpmbuild(8) 中,有关 过 去记录在 rpm(8) 中的,rpm 构建模式的文档。 将下面的这些添加到 /etc/popt 中,如果想使用 rpm 命令行运行 rpmbuild的话 : rpm exec --bp rpmb -bp rpm exec --bc rpmb -bc rpm exec --bi rpmb -bi rpm exec --bl rpmb -bl rpm exec --ba rpmb -ba rpm exec --bb rpmb -bb rpm exec --bs rpmb -bs rpm exec --tp rpmb -tp rpm exec --tc rpmb -tc rpm exec --ti rpmb -ti rpm exec --tl rpmb -tl rpm exec --ta rpmb -ta rpm exec --tb rpmb -tb rpm exec --ts rpmb -ts rpm exec --rebuild rpmb --rebuild rpm exec --recompile rpmb --recompile rpm exec --clean rpmb --clean rpm exec --rmsource rpmb --rmsource rpm exec --rmspec rpmb --rmspec rpm exec --target rpmb --target rpm exec --short-circuit rpmb --short-circuit FILES rpmrc 配置文件 /usr/lib/rpm/rpmrc /usr/lib/rpm/redhat/rpmrc /etc/rpmrc ~/.rpmrc Macro 宏定义文件 /usr/lib/rpm/macros /usr/lib/rpm/redhat/macros /etc/rpm/macros ~/.rpmmacros Database 数据库 /var/lib/rpm/Basenames /var/lib/rpm/Conflictname /var/lib/rpm/Dirnames /var/lib/rpm/Filemd5s /var/lib/rpm/Group /var/lib/rpm/Installtid /var/lib/rpm/Name /var/lib/rpm/Packages /var/lib/rpm/Providename /var/lib/rpm/Provideversion /var/lib/rpm/Pubkeys /var/lib/rpm/Removed /var/lib/rpm/Requirename /var/lib/rpm/Requireversion /var/lib/rpm/Sha1header /var/lib/rpm/Sigmd5 /var/lib/rpm/Triggername Temporary 临时文件 /var/tmp/rpm* SEE ALSO popt(3), rpm2cpio(8), rpmbuild(8), http://www.rpm.org/ <URL:http://www.rpm.org/> AUTHORS Marc Ewing <[email protected]> Jeff Johnson <[email protected]> Erik Troan <[email protected]> TRANSBY LinuxForum.Net CMPP 中文手册页计划 [url=http://cmpp.linuxforum.net] * Tue May 3 2005 Yuan Yijun <[email protected]> rpm-4.4.1-3 - 初始版本, 来自于 rpm 的手册页集合 Red Hat, Inc. 09 June 2002 RPM(8)
RPMBUILD(8) Red Hat Linux RPMBUILD(8) NAME rpmbuild - 构建 RPM 打包 SYNOPSIS 构建打包: rpmbuild {-ba|-bb|-bp|-bc|-bi|-bl|-bs} [rpmbuild-options] SPECFILE ... rpmbuild {-ta|-tb|-tp|-tc|-ti|-tl|-ts} [rpmbuild-options] TARBALL ... rpmbuild {--rebuild|--recompile} SOURCEPKG ... 其他: rpmbuild --showrc rpmbuild 选项 [--buildroot DIRECTORY] [--clean] [--nobuild] [--rmsource] [--rmspec] [--short-circuit] [--sign] [--target PLATFORM] DESCRIPTION rpmbuild 是用来构建软件的二进制和源代码打包的。一个软件包 package 包 括 文 件的归档以及用来安装和卸载归档中文件的元数据。元数据包括辅助脚本,文 件属性,以及有关的描述性的信息。软件包有两种 package:二进制软件包, 用 来 封装要安装的软件,源代码软件包,包含了源代码和要构建二进制打包需要的 内容。 必须选择下列基本模式之一:0 Build Package, Build Package from Tarball, Recompile Package, Show Configuration. 一般的选项 这些选项可以用于所有不同的模式。 -?, --help 输出较长的帮助信息 --version 输出一行信息,包含 rpmbuild 的版本号 --quiet 输出尽可能少的信息 - 通常只有错误信息才会显示出来 -v 输出冗余信息 - 通常常规的进度信息都将被显示 -vv 输出大量丑陋的调试信息 --rcfile FILELIST FILELIST 中冒号分隔的每个文件名都被 rpm 按顺序读取,从中获得配置 信息。只有列表的第一个文件必须存在,波浪线将被替换为 $HOME。默认 的 FILELIST 是 /usr/lib/rpm/rpmrc:/usr/lib/rpm/red- hat/rpmrc:/etc/rpmrc:~/.rpmrc --pipe CMD 将 rpm 的输出通过管道送到命令 CMD。 --dbpath DIRECTORY 使用 DIRECTORY 中的数据库,而不是默认的路径 /var/lib/rpm --root DIRECTORY 以 DIRECTORY 作为根文件系统,进行所有操作。这意味着将使用 DIREC- TORY 中 的 数 据库来进行依赖性检测,任何小程序 (也就是安装中的 %post 和构建中的 %prep) 都将在一个 chroot(2) 到 DIRECTORY 之后执 行。 构建选项 构建命令的一般形式是 rpmbuild -bSTAGE|-tSTAGE [ rpmbuild-options ] FILE ... 如 果要用某个 spec 文件构建,使用 -b 参数。如果需要根据一个可能是压缩过 的 tar 归档文件中的 spec 文件构建,就使用 -t 参数。第一个参数之后的字符 STAGE 指定了要完成的构建和打包的阶段,是下列其中之一: -ba 构建二进制和源代码打包 (在执行 %prep, %build 和 %install 之后) -bb 构建二进制打包 (在执行 %prep, %build 和 %install 之后) -bp 执行 spec 文件的 "%prep" 阶段。通常,这会解包源代码并应用补丁 -bc 执行 spec 文件的 "%build" 阶段 (在执行了 %prep 阶段之后)。这通常 等价于执行了一次 "make" -bi 执行 spec 文件的 "%install" 阶段 (在执行了 %prep 和 %build 阶 段 之后)。这通常等价于执行了一次 "make install" -bl 执行一次 "列表检查"。spec 文件的 "%files" 段落中的宏被扩展,检测 是否每个文件都存在。 -bs 只构建源代码打包 还可以用下列选项: --buildroot DIRECTORY 在构建时,使用目录 DIRECTORY 覆盖默认的值 --clean 在制作打包之后删除构建树 --nobuild 不执行任何构建步骤。用于测试 spec 文件 --rmsource 在构建后删除源代码 (也可以单独使用,例 如 "rpmbuild --rmsource foo.spec") --rmspec 在 构 建 之 后 删 除 spec 文件 (也可以单独使用,例如 "rpmbuild --rmspec foo.spec") --short-circuit 直接跳到指定阶段 (也就是说,跳过指定阶段前面的所有步骤)。只有 与 -bc 或 -bi 连用才有意义。 --sign 在打包中包含 GPG 签名。签名可以用来校验打包的完整性和来源。参见 rpm(8) 的 "GPG 签名" 章节中的配置细节。 --target PLATFORM 在构建时,将 PLATFORM 解析为 arch-vendor-os,并以此设置宏 %_tar- get, %_target_cpu, 和 %_target_os 的值。 重建和重编译选项 还有两种发起构建的方法: rpmbuild --rebuild|--recompile SOURCEPKG ... 这样执行的话,rpmbuild 安装指定的源代码打包,然后进行准备,编译和安装。 另外,--rebuild 构建一个新的二进制打包,在构建结束时,构建目录被删除 ( 就好像用了 --clean),源代码和 spec 文件也被删除。 SHOWRC 命令 rpmbuild --showrc 将显示 rpmbuild 使用的,在 rpmrc 和 macros 配置文件中定义的选项的值。 FILES rpmrc 配置文件 /usr/lib/rpm/rpmrc /usr/lib/rpm/redhat/rpmrc /etc/rpmrc ~/.rpmrc Macro 宏定义文件 /usr/lib/rpm/macros /usr/lib/rpm/redhat/macros /etc/rpm/macros ~/.rpmmacros Database 数据库 /var/lib/rpm/Basenames /var/lib/rpm/Conflictname /var/lib/rpm/Dirnames /var/lib/rpm/Filemd5s /var/lib/rpm/Group /var/lib/rpm/Installtid /var/lib/rpm/Name /var/lib/rpm/Packages /var/lib/rpm/Providename /var/lib/rpm/Provideversion /var/lib/rpm/Pubkeys /var/lib/rpm/Removed /var/lib/rpm/Requirename /var/lib/rpm/Requireversion /var/lib/rpm/Sha1header /var/lib/rpm/Sigmd5 /var/lib/rpm/Triggername Temporary 临时文件 /var/tmp/rpm* SEE ALSO popt(3), rpm2cpio(8), gendiff(1), rpm(8), http://www.rpm.org/ <URL:http://www.rpm.org/> AUTHORS Marc Ewing <[email protected]> Jeff Johnson <[email protected]> Erik Troan <[email protected]> TRANSBY LinuxForum.Net CMPP 中文手册页计划 [url=http://cmpp.linuxforum.net] * Tue May 3 2005 Yuan Yijun <[email protected]> rpm-4.4.1-3 - 初始版本, 来自于 rpm 的手册页集合 Red Hat, Inc. 09 June 2002 RPMBUILD(8)
作者: bbbush 发布时间: 2005-05-13
还是没找到具体的解决办法~
作者: 13251947
我只能rebuild出这些包
kernel kernel-hugemem kernel-hugemem-unsupported kernel-smp kernel-smp-unsupported kernel-unsupported 可这机个包怎么可以得到呢? kernel-BOOT kernel-doc kernel-source |
作者: 13251947 发布时间: 2005-05-13
%define with_xorg 1 %define dist fc4 Name: cce Version: 0.51 Release: 3.%{dist} Summary: A CJK console with many input method Summary(zh_CN): 一个自带输入法的 CJK 控制台 Group: System Environment/Shells License: GPL URL: http://sourceforge.net/projects/cce2k/ Source0: http://dl.sourceforge.net/cce2k/cce-0.51-02132004-dist.tgz NoSource: 0 Patch0: cce-0.51-gcc4.patch Patch1: cce-0.51-cin2tab-makefile.patch Patch2: cce-0.51-doc-makefile.patch Patch3: cce-0.51-default-im.diff BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) Requires: SDL, freetype >= 2.1, gpm BuildRequires: SDL-devel, freetype-devel >= 2.1, gpm-devel %if %{with_xorg} Requires: xorg-x11 BuildRequires: xorg-x11-devel %else Requires: XFree86 BuildRequires: XFree86-devel %endif %description CCE let you display and input Chinese/Japanese/Korean/UTF8 in many OS: Linux *BSD Solaris LynxOS QNX SCOUnix Minix Hurd BeOS Windows Darwin MacOSX. It supports console(framebuffer/VGA) & X11(through GGI/SDL), bitmap/TrueType fonts and many input methods. %description -l zh CCE 使您能在多种操作系统里显示和输入中文/日文/韩文/UTF-8: Linux *BSD Solaris LynxOS QNX SCOUnix Minix Hurd BeOS Windows Darwin MacOSX。它支持控制台(祯缓冲/VGA)以及 X11(通过 GGI/SDL),bitmap/TrueType 字体和众多输入法。 %prep %setup -q %patch -p1 %patch1 -p1 %patch2 -p1 %patch3 -p1 %build %configure --enable-gpmmouse --enable-fb --enable-sdl --enable-freetype --enable-filter --enable-memfile --enable-x11fonts make %install rm -rf $RPM_BUILD_ROOT %makeinstall pushd %{buildroot}%{_bindir} chmod 0755 cce rm -rf cceb5 cceconv ccegbk ccejis cceksc popd mkdir -p %{buildroot}%{_sysconfdir} pushd %{buildroot}%{_datadir}/cce mv cce.cfg %{buildroot}%{_sysconfdir}/cce.conf rm -f cin2tab bdf2bin popd %clean rm -rf $RPM_BUILD_ROOT %post cd %{_bindir} ln -sf cce cceb5 ln -sf cce cceconv ln -sf cce ccegbk ln -sf cce ccejis ln -sf cce cceksc cd %{_datadir}/cce ln -sf /etc/cce.conf cce.cfg %preun if [ $1 -eq 0 ]; then cd %{_bindir} rm -f cceb5 cceconv ccegbk ccejis cceksc cd %{_datadir}/cce rm -f cce.cfg fi %files %defattr(-,root,root,-) %doc AUTHORS BUGS COPYING ChangeLog INSTALL README* TODO %config(noreplace) %{_sysconfdir}/cce.conf %{_bindir}/* %{_mandir}/man1/* %{_datadir}/%{name} %changelog * Sun Jun 5 2005 Yuan Yijun <[email protected]> - 0.51-3 - move pushd and popd to %post to avoid check-files error set default im to 全拼 since we cannot use 智能拼音 as normal user :( * Sat Jun 4 2005 Yuan Yijun <[email protected]> - 0.51-2 - use pushd and popd in spec by gugong @ linuxfans patch doc/Makefile.am by sunmoon1997 @ linuxsir patch inputs/all/Makefile.in and input/utils/Makefile.in since we don't install cin2tab so we simply set CCELIB to ../utils/ * Mon Apr 25 2005 Yuan Yijun <[email protected]> - compile on gcc4 for fedora. * Sun Sep 19 2004 kde <[email protected]> - 0.51 release - initialize the first spec file
%define dist fc4 Name: cce-24x24fonts Version: 0.50 Release: 1.%{dist} Summary: 24x24 fonts for cce Summary(zh_CN): 用于 cce 的 24x24 点阵字体 Group: Documentation License: Distributable URL: http://dl.sourceforge.net/cce/cce-24x24fonts-dist.tgz Source0: http://dl.sourceforge.net/cce/cce-24x24fonts-dist.tgz NoSource: 0 Patch0: cce-24x24fonts-gcc4.patch BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) Requires: cce %description 24x24 fonts for cce %description -l zh 用于 cce 的 24x24 点阵字体 %prep %setup -q %patch0 -p1 %build %configure make #%{?_smp_mflags} %install rm -rf $RPM_BUILD_ROOT %makeinstall pushd %{buildroot}%{_datadir}/cce rm -f bdf2bin popd %clean rm -rf $RPM_BUILD_ROOT %files %defattr(-,root,root,-) %doc AUTHORS ChangeLog COPYING INSTALL NEWS README %{_datadir}/cce/* %changelog * Sun Jun 5 2005 Yuan Yijun <[email protected]> - 0.50-1 - initial import
1. fedora-extras 提供了 fedora-rpmdevtools 工具。使用 yum install fedora-rpmdevtools 来安装这个工具。这个工具包含了很多辅助工具,包括
/usr/bin/fedora-buildrpmtree /usr/bin/fedora-diffarchive /usr/bin/fedora-extract /usr/bin/fedora-installdevkeys /usr/bin/fedora-kmodhelper /usr/bin/fedora-md5 /usr/bin/fedora-newrpmspec /usr/bin/fedora-rmdevelrpms /usr/bin/fedora-rpmchecksig /usr/bin/fedora-rpminfo /usr/bin/fedora-rpmvercmp /usr/bin/fedora-wipebuildtree /usr/bin/spectool
2. 制作 spec 时应当以普通用户身份,否则可能把系统搞挂掉,因为你不知道在编译过程中,这个软件包会做什么坏事。为了以普通用户身份操作,运行 fedora-bulidrpmtree 命令。这个命令在个人目录下建立一个文件夹 rpmbuild,内容类似 /usr/src/redhat,并且自动配置 $HOME/.rpmmacros 为
[yuan2@geeks ~]$ cat .rpmmacros %_topdir %(echo $HOME)/rpmbuild %_smp_mflags -j3 %__arch_install_post /usr/lib/rpm/check-rpaths /usr/lib/rpm/check-buildroot
3. 第一步当然是收集源代码,准备好完整的源代码,还要详细记录下载地址。如果源代码来自 cvs,通常官方发布的不同时间的 cvs 源代码打包都有着相同的名字,例如 http://download.gro.clinux.org/__tar...cvsroot.tar.gz 的名字总是 fedora-cvsroot.tar.gz,这在自动编译的 spec 中是不允许的,因为在验证源代码的 SHA1SUM 时候,会出现一个软件包有多个 SHA1SUM 的情况。因此下载后应该把源码包改名,加上打包的日期。例如,今天是 20050605 那么可以用 fedora-cvsroot-20050605.tar.gz 作为源码包的名字;又如 fontconfig-2.3.2.20050527.tar.bz2 这样带有版本号和日期的名字。当然,这种处理只限于 cvs 源代码无法区分的情况。
4. 有一个工具 fedora-newrpmspec 可以用来生成一个 newpackage.spec 文件。这个文件是个框架,内容大概就是这样
Name: Version: Release: 1 Summary: Group: License: URL: Source0: BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) BuildRequires: Requires: %description %prep %setup -q %build %configure make %{?_smp_mflags} %install rm -rf $RPM_BUILD_ROOT make install DESTDIR=$RPM_BUILD_ROOT %clean rm -rf $RPM_BUILD_ROOT %files %defattr(-,root,root,-) %doc %changelog
5. 为软件包选择一个合适的名称。通常的规矩是上游叫它什么,软件包的名称就叫什么。如果上游没有明确的名称,或者使用可执行文件的名称会更合适,那么就使用可执行文件名。如果是数据文件,那么就查看一下惯例的做法,例如 openoffice.org-langpack-zh_CN 这样的名称,或者 fonts-xorg-ISO8859-9-100dpi 这样的名称。直接使用源码包的名称也是个好办法。一旦选好了名称,例如我们的 cce 选定之后,将 newpackage.spec 移动到 $(rpmbuild)/SPECS 目录:mv newpackage.spec $(HOME)/rpmbuild/SPECS/cce.spec
6. 填充 spec 的内容。如果包含中文,修改后一定要用 UTF-8 来保存文件!
6.1 spec 的最前面是 %define 部分,定义 %define dist fc4 只是权益之计,因为还不知道 %{dist} 究竟怎么用 (FIXME! ) 接下来,Name 是刚才选定的,Release 默认是 1,每次修改 spec 或者 patch 都应该把 Release 增加 1,并且这里加上了 %{dist} 后缀。Summary 只能有一句,并且绝对不能太长。有个很奇怪的限制,这句话的最后不能用句点。这也是用 rpmlint 查出来的。
6.2 Group 的定义,参见 /usr/share/doc/rpm-*/GROUPS 文件,据说这个定义已经好多年没有变动了,也许以后也不可能再变了,虽然不合理,但是不能捏造。Group(zh_CN) 是按照 magic 的规矩捏造的。License 是 GPL 或者 Distributable 之类的,这里不能用 Copying,只能用 License,否则编译会报错。源代码地址 Source0 必须带有 URL,这样自动编译时,可以验证源代码是否可以下载。我喜欢在 Source0 后面再加上一个 NoSource 0 也就是在源代码srpms中只包含 spec 和 patch,这样发送给别人时会更方便一点 根据网上的文档,如果你的 spec 是重新写的,而其他人或者上游已经提供了一个 spec,那么可以在这里定义一个 Source99 来包含那份暂时不用的 spec,也许其他人有一天会用到。另外,按照网上的文档,不能在 Source0 中使用宏,这里也是自动编译的原因。
6.3 接下来是 Patch,再接下来是 Requires 等等。按照网上的文档,不要包含 Packager 和 Vendor 标记。这和使用 License 代替 Copying 一样是强制的规定,不知道为什么。Requires(pre) 和 Requires(post) 用来定义安装顺序,如果你的 scriptlet 要用到其他软件包,那么必须在 Requires(pre) 和 Requires(post) 里面定义他们。因为经常有这样的情况,一个软件包仅仅在安装和卸载时会用到 desktop-file-install 或者 alternatives 这些程序,而平时运行时不会使用它们,因此使用 Requires(pre) 和 Requires(post)。
6.4 %description 有一个很著名的限制,就是一行不能超过 80 个字符,否则会把某些终端搞乱掉。实际上除去回车,一行只能写 79 个字符了。使用 rpmlint 可以很容易检查到这些错误。%prep, %build 和 %install 是编译和安装的全过程,应该灵活地把握这个过程,利用各种宏。小心宏之间的不同之处。cce 倒是没什么特别的,不能使用默认的 make install DESTDIR=$RPM_BUILD_ROOT,应该用 %makeinstall,因为在所有的 Makefile.in 都定义了 CCE_SHARE_DIR=$(DESTDIR)$(datadir) (具体是怎么回事,我也说不明白 )。 cce 默认的 make install 很讨厌,把配置文件装在 /usr/share/cce/cce.cfg,并且把两个可执行文件也装到了 /usr/share/cce 目录,因此这里在 %install 把它们都删掉了。rpmlint 还检查到了 setuid 的问题,因此需要重新设置一下 cce 的文件模式,代价就是不能在 VGA 中使用,也不能使用智能拼音输入法,不能保存词库。为了通过 rpmlint 的检测,没有办法 :(
6.5 在小程序 (%pre, %post, %preun, %postun, 以及 triggers) 这里,好像有很多规定,包括使用 desktop-file-install,以及刷新 icon cache 等等,不过这里还没有用到。这里是在 %post 和 %preun 建立了一些链接。不知道为什么我的系统里不能在 %files 中包含链接,所以只好在 scriptlet 里面做了 (FIXME! ) 另外,要判断 $1 的值,来决定是否进行操作。大概的规矩就是,在升级时,%preun 和 %postun 的 $1=1,在单纯卸载时 $1=0,这样就不会因为升级而错误地执行卸载程序。参见 http://www.fedora.us/wiki/PackagingHints ,这个页面应该已经搬到了 http://fedoraprojects.org 但是从 livna 只追踪到了 fedora.us 的链接 :(
6.6 %files 这一处,要设定权限,区分不同的文件类型。如果有其他语言的 man 文本,还应该用 %lang(zh_CN) 来区分语言,可以参考 rpm.spec 里面的示例。%changelog 的格式中,要记住更新第一行最后的软件包版本。
7. 做好了 rpm 以后就是打包。通常,在 SOURCES 目录,将软件包源代码解压,随时准备打 patch。使用 gendiff 命令可以很容易地生成符合要求的 patch,每做好一个 patch 之后只要稍微修改 spec 就可以了。每个 patch 应该对应一种修改,不要把好多 patch 都合到一起。可以顺利编译之后,使用 rpmlint 来校验生成的 rpm,会发现很多需要改的地方。这个过程听起来不是很难,习惯了之后,总是几个命令 vi, gendiff, vi, rpmbuild, vi, rpmlint ……
8. 提交啊,fedora-cn gro cvs,还有邮件列表,论坛,各发一份。修改得烦死了。
-
作者: bbbush 发布时间: 2005-06-05
Mock Readme Mock is a simple chroot/rpm building program. It doesn't do anything terribly fancy other than build a single srpm at a time in a chroot. You invoke it as: mock -r name-of-chroot /path/to/srpm options: -r CHROOT chroot name/config file name default: chroot.cfg --no-clean do not clean chroot before building --arch=ARCH target build arch --debug Output copious debugging information --resultdir=RESULTDIR path for resulting files to be put --statedir=STATEDIR path for state dirresulting files to be put --uniqueext=UNIQUEEXT Arbitrary, unique extension to append to buildroot directory name commands: init - initialize a chroot (install pkgs, setup devices, etc,) then exit clean - purge the chroot tree - normally this happens right before a build but this is for the tidy-minded rebuild <srpm> - for mach compatibility mock does: - builds the chroot - takes the srpm, rebuilds into another srpm - it does this to make sure that the build deps in the spec file are made in the right environment. - takes the build deps from the new srpm and installs them. - rebuilds the new srpm into binary packages - copies the binary packages into the result dir - logs nicely so that chroot creation and build logs are separate - outputs little unless it needs to. TODO: document more TODO: man page? |
作者: bbbush 发布时间: 2005-11-28
开始的时候主要是一些语法错误 后来更正之后 发现 打包出来的rpm 是空的 郁闷死了 弄了好长时间也没发现什么错误 一行行的看 最后才发现 原来 %doc下面少了要打包的文件
加上 %{_bindir}/* 就好了 同样 可以加上
%{_infodir}/*
%{_mandir}/*
%{_datadir}/×
不然打出来的就是空包了 我郁闷了好久
下面是我为conky打包的spec文件 (应该是minimal的 )
Name: conky Version: 1.4.2 Release: 1%{?dist} Summary: conky Group: User Interface/X License: GPLv2 URL: www.conky.org Source0: %{name}-%{version}.tar.bz2 BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) BuildRequires: fontconfig Requires: fontconfig %description %prep %setup -q %build %configure make %{?_smp_mflags} %install rm -rf $RPM_BUILD_ROOT make install DESTDIR=$RPM_BUILD_ROOT %clean rm -rf $RPM_BUILD_ROOT %files %defattr(-,root,root,-) %doc %{_bindir}/* %changelog
作者: fakeid 发布时间: 2006-11-06
作者: mcpsx 发布时间: 2006-11-06
作者: sendney 发布时间: 2006-11-06
热门阅读
-
office 2019专业增强版最新2021版激活秘钥/序列号/激活码推荐 附激活工具
阅读:74
-
如何安装mysql8.0
阅读:31
-
Word快速设置标题样式步骤详解
阅读:28
-
20+道必知必会的Vue面试题(附答案解析)
阅读:37
-
HTML如何制作表单
阅读:22
-
百词斩可以改天数吗?当然可以,4个步骤轻松修改天数!
阅读:31
-
ET文件格式和XLS格式文件之间如何转化?
阅读:24
-
react和vue的区别及优缺点是什么
阅读:121
-
支付宝人脸识别如何关闭?
阅读:21
-
腾讯微云怎么修改照片或视频备份路径?
阅读:28