一、介绍
RPM全称是 Red Hat Package Manager(Red Hat包管理器)。几乎所有的 Linux 发行版本都使用这种形式的软件包管理安装、更新和卸载软件。
RPM是一个开放的软件包管理系统。它工作于Red Hat Linux以及其它Linux和UNIX 系统,可被任何人使用。redhat软件公司鼓励其它厂商来了解RPM并在自己的产品中使用它。RPM的发布基于GPL协议。对于最终用户来说,使用RPM所提供的功能来维护系统是比较容易和轻松的。安装、卸载和升级RPM软件包只需一条命令就可以搞定。RPM维护了一个所有已安装的软件包和文件的数据库,可以让用户进行查询和验证工作。在软件包升级过程中,RPM会对配置文件进行特别处理,绝对不会丢失以往的定制信息。对于程序员RPM可以让我们连同软件的源代码打包成源代码和二进制软件包供最终用户使用。
RPM拥有功能强大的查询选项。我们可以搜索数据库来查询软件包或文件。也可以查出某个文件属于哪个软件包或出自哪儿。RPM软件包中的文件是以压缩格式存放的,拥有一个定制的二进制头文件,其中包含有关包和内容的信息,可以让我们对单个软件包的查询简便又快速。
RPM另一个强大的功能是进行软件包的验证。如果我们担心误删了某个软件包中的某个文件,我们就可以对它进行验证。任何非正常现象将会被通知。如果需要的话还可以重新安装该软件包。在重新安装过程中,所有被修改过的配置文件将被保留。
RPM设计目标之一就是要保持软件包的原始特征, 就象该软件的原始发布者发布软件时那样。通过使用RPM我们可以拥有最初的软件和最新的补丁程序,还有详细的软件构建信息。
概括的说:RPM有五种基本的操作功能(不包括创建软件包):安装、卸载、升级、查询、和验证。关于rpm命令的使用我们可以用以下命令:
1 |
[root@hostname root]rpm -help |
来获的。
二、RPM基本操作
1) 安装
rpm -i ( or –install) options file1.rpm … fileN.rpm 通过rpm -ivh可以把rpm软件包安装到系统中,当然也可以使用不同的参数选项,笔者建议使用-ivh ,使用该选项可以解决大部分rpm软件包的安装,至于详细的参数说明可用查看rpm的man 文档。
2 )删除
rpm -e ( or –erase) options pkg1 … pkgN 如果某个软件包你再也不想使用了,那就用以上这个命令彻底的把你指定的rpm软件包清除掉把。
3 )升级
rpm -U ( or –upgrade) options file1.rpm … fileN.rpm 由于开源软件更新速度快,用户当然要使用最新版本的软件包,此时最合适的就是rpm升级功能,当然最理想的参数选项就是-Uvh。
4 )查询
rpm -q ( or –query) options 实际上我们通常使用rpm工具最多的功能还是它的查询功能,比如查看软件包的版本、依赖关系等软件包的详细说明都要用到。最有用的参数选项是-qpi。
5 )校验已安装的软件包
rpm -V ( or –verify, or -y) options 一般我们可用通过该命令来验证已安装软件包,根据笔者的经验该命令一般没什么用途,只做一个了解就ok了。
能熟练掌握以上命令以及部分参数含义,管理日常的rpm软件包就不成问题了。然而随着Linux风靡全球,越来越多的开发者喜欢采用RPM格式来发布自己的软件包。那么RPM软件包是怎样制作的呢?对大多数Linux开发工程师来说是比较陌生的。
其实,制作RPM软件包并不是一件复杂的工作,其中的关键在于编写SPEC软件包描述文件。要想制作一个rpm软件包就必须写一个软件包描述文件(SPEC)。这个文件中包含了软件包的诸多信息,如软件包的名字、版本、类别、说明摘要、创建时要执行什么指令、安装时要执行什么操作、以及软件包所要包含的文件列表等等。
三、关键字
描述文件说明如下:
(1) 文件头
一般的spec文件头包含以下几个域:
Summary:
用一句话概括该软件包尽量多的信息。
Name:
软件包的名字,最终RPM软件包是用该名字与版本号,释出号及体系号来命名软件包的。
Version:
软件版本号。仅当软件包比以前有较大改变时才增加版本号。
Release:
软件包释出号。一般我们对该软件包做了一些小的补丁的时候就应该把释出号加1。
Vendor:
软件开发者的名字。
Copyright:
软件包所采用的版权规则。具体有:GPL(自由软件),BSD,MIT,Public Domain(公共域),Distributable(贡献),commercial(商业),Share(共享)等,一般的开发都写GPL。
Group:
软件包所属类别,具体类别有:
Amusements/Games (娱乐/游戏)
Amusements/Graphics(娱乐/图形)
Applications/Archiving (应用/文档)
Applications/Communications(应用/通讯)
Applications/Databases (应用/数据库)
Applications/Editors (应用/编辑器)
Applications/Emulators (应用/仿真器)
Applications/Engineering (应用/工程)
Applications/File (应用/文件)
Applications/Internet (应用/因特网)
Applications/Multimedia(应用/多媒体)
Applications/Productivity (应用/产品)
Applications/Publishing(应用/印刷)
Applications/System(应用/系统)
Applications/Text (应用/文本)
Development/Debuggers (开发/调试器)
Development/Languages (开发/语言)
Development/Libraries (开发/函数库)
Development/System (开发/系统)
Development/Tools (开发/工具)
Documentation (文档)
System Environment/Base(系统环境/基础)
System Environment/Daemons (系统环境/守护)
System Environment/Kernel (系统环境/内核)
System Environment/Libraries (系统环境/函数库)
System Environment/Shells (系统环境/接口)
User Interface/Desktops(用户界面/桌面)
User Interface/X (用户界面/X窗口)
User Interface/X Hardware Support (用户界面/X硬件支持)
Source:
源程序软件包的名字。如 stardict-2.0.tar.gz。
%description:
软件包详细说明,可写在多个行上。
spec脚本包括很多关键字,主要有:
引用
Name: 软件包的名称,后面可使用%{name}的方式引用
Summary: 软件包的内容概要
Version: 软件的实际版本号,例如:1.0.1等,后面可使用%{version}引用
Release: 发布序列号,例如:1linuxing等,标明第几次打包,后面可使用%{release}引用
Group: 软件分组,建议使用标准分组
License: 软件授权方式,通常就是GPL
Source: 源代码包,可以带多个用Source1、Source2等源,后面也可以用%{source1}、%{source2}引用
BuildRoot: 这个是安装或编译时使用的“虚拟目录”,考虑到多用户的环境,一般定义为:
%{_tmppath}/%{name}-%{version}-%{release}-root
或
%{_tmppath}/%{name}-%{version}-%{release}-buildroot-%(%{__id_u} -n}
该参数非常重要,因为在生成rpm的过程中,执行make install时就会把软件安装到上述的路径中,在打包的时候,同样依赖“虚拟目录”为“根目录”进行操作。
后面可使用$RPM_BUILD_ROOT 方式引用。
URL: 软件的主页
Vendor: 发行商或打包组织的信息,例如RedFlag Co,Ltd
Disstribution: 发行版标识
Patch: 补丁源码,可使用Patch1、Patch2等标识多个补丁,使用%patch0或%{patch0}引用
Prefix: %{_prefix} 这个主要是为了解决今后安装rpm包时,并不一定把软件安装到rpm中打包的目录的情况。这样,必须在这里定义该标识,并在编写%install脚本的时候引用,才能实现rpm安装时重新指定位置的功能
Prefix: %{_sysconfdir} 这个原因和上面的一样,但由于%{_prefix}指/usr,而对于其他的文件,例如/etc下的配置文件,则需要用%{_sysconfdir}标识
Build Arch: 指编译的目标处理器架构,noarch标识不指定,但通常都是以/usr/lib/rpm/marcros中的内容为默认值
Requires: 该rpm包所依赖的软件包名称,可以用>=或<=表示大于或小于某一特定版本,例如:
libpng-devel >= 1.0.20 zlib
※“>=”号两边需用空格隔开,而不同软件名称也用空格分开
还有例如PreReq、Requires(pre)、Requires(post)、Requires(preun)、Requires(postun)、BuildRequires等都是针对不同阶段的依赖指定
Provides: 指明本软件一些特定的功能,以便其他rpm识别
Packager: 打包者的信息
spec脚本的主体中也包括了很多关键字和描述,下面会一一列举。我会把一些特别需要留意的地方标注出来。
%prep 预处理脚本
%setup -n %{name}-%{version} 把源码包解压并放好
通常是从/usr/src/asianux/SOURCES里的包解压到/usr/src/asianux/BUILD/%{name}-%{version}中。
一般用%setup -c就可以了,但有两种情况:一就是同时编译多个源码包,二就是源码的tar包的名称与解压出来的目录不一致,此时,就需要使用-n参数指定一下了。
%patch 打补丁
通常补丁都会一起在源码tar.gz包中,或放到SOURCES目录下。一般参数为:
%patch -p1 使用前面定义的Patch补丁进行,-p1是忽略patch的第一层目录
%Patch2 -p1 -b xxx.patch 打上指定的补丁,-b是指生成备份文件
◎补充一下
%setup -n newdir 将软件包解压在newdir目录。
%setup -c 解压缩之前先产生目录。
%setup -b num 将第num个source文件解压缩。
%setup -T 不使用default的解压缩操作。
%setup -T -b 0 将第0个源代码文件解压缩。
%setup -c -n newdir 指定目录名称newdir,并在此目录产生rpm套件。
%patch 最简单的补丁方式,自动指定patch level。
%patch 0 使用第0个补丁文件,相当于%patch ?p 0。
%patch -s 不显示打补丁时的信息。
%patch -T 将所有打补丁时产生的输出文件删除。
%configure 这个不是关键字,而是rpm定义的标准宏命令。意思是执行源代码的configure配置
在/usr/src/asianux/BUILD/%{name}-%{version}目录中进行 ,使用标准写法,会引用/usr/lib/rpm/marcros中定义的参数。
另一种不标准的写法是,可参考源码中的参数自定义,例如:
%build 开始构建包
在/usr/src/asianux/BUILD/%{name}-%{version}目录中进行make的工作 ,常见写法:
都是一些优化参数,定义在/usr/lib/rpm/marcros中
%install 开始把软件安装到虚拟的根目录中
在/usr/src/asianux/BUILD/%{name}-%{version}目录中进行make install的操作。这个很重要,因为如果这里的路径不对的话,则下面%file中寻找文件的时候就会失败。 常见内容有:
%makeinstall 这不是关键字,而是rpm定义的标准宏命令。也可以使用非标准写法:
或
需要说明的是,这里的%install主要就是为了后面的%file服务的。所以,还可以使用常规的系统命令:
cp -a * $RPM_BUILD_ROOT/
%clean 清理临时文件
通常内容为:
rm -rf $RPM_BUILD_DIR/%{name}-%{version}
$RPM_BUILD_ROOT是指开头定义的BuildRoot,而$RPM_BUILD_DIR通常就是指/usr/src/asianux/BUILD,其中,前面的才是%file需要的。
%pre rpm安装前执行的脚本
%post rpm安装后执行的脚本
%preun rpm卸载前执行的脚本
%postun rpm卸载后执行的脚本
前者在升级的时候会执行,后者在升级rpm包的时候不会执行
%files 定义那些文件或目录会放入rpm中
这里会在虚拟根目录下进行,千万不要写绝对路径,而应用宏或变量表示相对路径。 如果描述为目录,表示目录中除%exclude外的所有文件。
%defattr (-,root,root) 指定包装文件的属性,分别是(mode,owner,group),-表示默认值,对文本文件是0644,可执行文件是0755
%exclude 列出不想打包到rpm中的文件
※小心,如果%exclude指定的文件不存在,也会出错的。
%changelog 变更日志
五、打包编译
如果想发布rpm格式的源码包或者是二进制包,就要使用rpmbuild工具(rpm最新打包工具)。如果我们已经根据本地源码包的成功编译安装而写了spec文件(该文件要以.spec结束),那我们就可以建立一个打包环境,也就是目录树的建立,一般是在/usr/src/redhat/目录下建立5个目录。它门分别是BUILD、SOURCE、SPEC、SRPM、RPM。其中BUILD目录用来存放打包过程中的源文件,SOURCE用来存放打包是要用到的源文件和patch,SPEC用来存放spec文件,SRPM、RPM分别存放打包生成的rpm格式的源文件和二进制文件。当然我们可以根据需要来选用不同的参数打包文件,笔者总结如下3条。
打包软件安装
1 |
yum install rpm-build |
1) 只生成二进制格式的rpm包
rpmbuild -bb xxx.spec
用此命令生成软件包,执行后屏幕将显示如下信息:(每行开头为行号)
1 2 3 4 5 6 7 |
1 Executing: %prep 2 + umask 022 3 + cd /usr/src/dist/BUILD 4 + exit 0 5 Executing: %build 6 + umask 022 7 + cd /usr/src/dist/BUILD |
生成的文件会在刚才建立的RPM目录下存在。
2)只生成src格式的rpm包
1 |
rpmbuild -bs xxx.spec |
生成的文件会在刚才建立的SRPM目录下存在。
3) 只需要生成完整的源文件
1 |
rpmbuild -bp xxx.spec |
源文件存在目录BUILD下。
读者朋友可能对这个命令不太明白,这个命令的作用就是把tar包解开然后把所有的补丁文件合并而生成一个完整的具最新功能的源文件。
4) 完全打包
1 |
rpmbuild -ba xxx.spec |
产生以上3个过程分别生成的包。存放在相应的目录下。
软件包制作完成后可用rpm命令查询,看看效果。如果不满意的话可以再次修改软件包描述文件,重新运行以上命令产生新的RPM软件包。
六、实例分析
通过第一部分的介绍,我们对软件包的管理以及spec文件的一些细节应该掌握的差不多了,接下来通过分析kaffeine.spec(kaffeine是linux平台下的媒体播放器)文件来让读者朋友实践一回spec文件的规范和书写。
Kaffeine.spec文件内容如下:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
%define debug_package %{nil} Name: kaffeine Version: 0.4.3 Release: 25 Summary: A xine-based Media Player for KDE Group: Applications/Multimedia License: GPL URL: http://kaffeine.sourceforge.net/ Source0: kaffeine-0.4.3.tar.bz2 Source1: logo.png Source2: icon.tgz Source3: kaffeine.desktop Source4: codecs.tgz Patch: kaffeine-0.4.3-fix-hide-crash.patch Patch1:kaffeine-0.4.3-without-wizard.patch BuildRoot: /var/tmp/kaffeine-root %description Kaffeine is a xine based media player for KDE3. It plays back CDs, DVDs, and VCDs. It also decodes multimedia files like AVI, MOV, WMV, and MP3 from local disk drives, and displays multimedia streamed over the Internet. It interprets many of the most common multimedia formats available - and some of the most uncommon formats, too. Additionally, Kaffeine is fully integrated in KDE3, it supports Drag and Drop and provides an editable playlist, a bookmark system, a Konqueror plugin, a Mozilla plugin, OSD an much more. |
以上这部分就是我们第一部分所说的文件头。这一部分主要包括软件包的名称、版本、源代码和patch等信息,通过这些关键字我们可以一目了然。查看以上内容,我们会全面了解该软件包。
接下来的这一个段就是核心部分,涉及到解包、补丁、编译、安装的过程。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 |
%prep %setup -q %patch -p1 %patch1 -p1 %Build make -f admin/Makefile.common cvs ./configure --prefix=/usr make #for mo files pushd po rm *.gmo make popd %install mkdir -p $RPM_BUILD_ROOT make install DESTDIR=$RPM_BUILD_ROOT mkdir -p $RPM_BUILD_ROOT/usr/share/services cp $RPM_BUILD_ROOT/usr/share/apps/kaffeine/mms.protocol $RPM_BUILD_ROOT/usr/share/services cp $RPM_BUILD_ROOT/usr/share/apps/kaffeine/rtsp.protocol $RPM_BUILD_ROOT/usr/share/services #mkdir -p $RPM_BUILD_ROOT/usr/lib/firefox/plugins #cp $RPM_BUILD_ROOT/usr/lib/kaffeineplugin/kaffeineplugin.so $RPM_BUILD_ROOT/usr/lib/firefox/plugins cp %{SOURCE1} $RPM_BUILD_ROOT/usr/share/apps/kaffeine rm -rf $RPM_BUILD_ROOT/usr/share/icons/hicolor/*/apps/kaffeine.png rm -rf $RPM_BUILD_ROOT/usr/share/icons/hicolor/*/apps/kaffeine-pause.png rm -rf $RPM_BUILD_ROOT/usr/share/icons/hicolor/*/apps/kaffeine-play.png rm -rf $RPM_BUILD_ROOT/usr/share/icons/hicolor/*/apps/kaffeine-record.png mkdir -p $RPM_BUILD_ROOT/usr/share/icons/crystalsvg tar zxvf %{SOURCE2} -C $RPM_BUILD_ROOT/usr/share/icons/crystalsvg mkdir -p $RPM_BUILD_ROOT/usr/share/applnk/App/Multimedia cp -r %{SOURCE3} $RPM_BUILD_ROOT/usr/share/applnk/App/Multimedia mkdir -p $RPM_BUILD_ROOT/usr/lib/win32 tar zxvf %{SOURCE4} -C $RPM_BUILD_ROOT/usr/lib/win32 %clean rm -rf $RPM_BUILD_ROOT %post ln -s /dev/cdrom /dev/dvd ln -s /dev/cdrom /dev/rdvd %files %defattr(-,root,root) /usr |
这部分内容与所要打的包有关系,我们要根据具体情况来写出编译过程。这部分内容是最复杂的内容,当然,我们也可以看出,这样的写法其实就是在写一种规范化的脚本,说到脚本,读者朋友门就应该领会到这部分内容的灵活性了。
1 2 3 4 5 6 7 8 9 10 11 |
%changelog * Fri Jul 1 2005 AiLin Yang <alyang@redflag-linux.com> -0.4.3-25 - modified the fullscreen bottom control panel * Fri Jun 17 2005 xxx <xxx@redflag-linux.com> -0.4.3-24 - Modified to use xshm as video driver. * Thu Jun 16 2005 AiLin Yang <alyang@redflag-linux.com> - delete the option of Embed in system tray in configwidget * Tue Jun 14 2005 AiLin Yang <alyang@redflag-linux.com> - add fullscreen bottom control panel - update kaffine to support my fullscreen bottom control panel |
这部分内容可以说是spec文件的最后内容了,它对团队软件开发以及后续的软件维护至关重要,它相当于一个日志,记录了所有的基于该软件包的修改、更新信息。
发表评论
要发表评论,您必须先登录。