鸟哥的 Linux 私房菜 -- RPM 与 SRPM 套件管理员

since2012/04/23

     
 
最近更新日期:2005/10/03
本文已不再维护,更新文章请参考此处
在上一章当中,我们介绍了以 Tarball 的方式来安装我们的套件,同时也说明了 Source code 与执行档之间的关系。不过,如果每次安装套件都需要进行编译的动作,那么实在很没效率!这个时候,由 Red Hat 公司所开发出来的套件管理程序( Red Hat Package Manager, RPM )可就帮了大忙了!RPM 除了可以用来安装套件之外,还可以进行查询、升级、反安装、以及其他验证等等的功能, 这些功能让我们在管理系统的套件上,更显的方便呢!此外,我们也可以利用 RPM 的原理来『自行创造自己的 RPM 档案』呢!

由于 RPM 实在是太好用了,目前主要的 Linux distributions 都是使用 RPM 来管理他们的套件,例如 Red Hat 系统 (含 Fedora ), SuSE 与改版后的 Mandriva ,所以,您不能不知道 RPM 是什么东西?该如何利用他,以及熟悉相关的功能!赶紧来参详参详!

大标题的图示前言
在前一章我们提到以原始码的方式来安装套件,也就是利用厂商释出的 Tarball 来进行套件与程序的安装。不过,您应该很容易发现,那就是每次安装套件都需要设定操作系统、 设定编译参数、实际的编译、最后还要依据个人喜好的方式来安装套件到定位。 这过程是真的很麻烦的,而且对于不熟整个系统的朋友来说,还真是累人啊!

那有没有想过,如果我的 Linux 系统与厂商的系统一模一样,那么在厂商的系统上面编译出来的执行档, 自然也就可以在我的系统上面跑啰!也就是说,厂商先在他们的系统上面编译好了我们使用者所需要的套件, 然后将这个编译好的可执行的套件直接释出给使用者来安装,如此一来,由于我们本来就使用厂商的 Linux distribution ,所以当然系统是一样的,那么使用厂商提供的编译过的可执行文件就没有问题啦! 说的比较白话一些,那就是利用类似 Windows 的安装方式,由程序开发者直接在已知的系统上面编译好,再将该程序直接给用户来安装,如此而已。

那么如果在安装的时候还可以加上一些与这些程序相关的信息,将他建立成为数据库, 那不就可以进行安装、反安装、升级与验证等等的相关功能啰( 类似 Windows 底下的『新增移除程序』 )?!确实如此,在 Linux 上面至少就有两种常见的这方面的套件管理员,分别是 RPM 与 Debian 的 dpkg ,其中又以 RPM 更常见。所以底下我们就来介绍一下 RPM 这个咚咚啰!


小标题的图示什么是 RPM 与 SRPM
RPM 全名是『 RedHat Package Manager 』简称则为 RPM 啦!顾名思义,当初这个套件管理的程序是由 Red Hat 这家公司发展出来的, 但其实在很多的其他套件也有相类似的套件管理程序。不过由于 RPM 使用上很方便,所以就成了目前最热门的套件管理程序啦!

那么什么是 RPM 呢?说的简单一点, RPM 是以一种数据库记录的方式来将你所需要的套件安装到你的 Linux 主机的一套管理程序。他最大的特点就是将您要安装的套件先编译过( 如果需要的话 )并且打包好了,透过包装好的套件里头默认的数据库记录, 记录这个套件要安装的时候必须要的相依属性模块( 就是你的 Linux 主机需要先存在的几个必须的套件 ),当安装在你的 Linux 主机时, RPM 会先依照套件里头的纪录数据查询 Linux 主机的相依属性套件是否满足, 若满足则予以安装,若不满足则不予安装。那么安装的时候就将该套件的信息整个写入 RPM 的数据库中,以便未来的查询、验证与反安装!这样一来的优点是:
  1. 由于已经编译完成并且打包完毕,所以安装上很方便( 不需要再重新编译 );
  2. 由于套件的信息都已经记录在 Linux 主机的数据库上,很方便查询、升级与反安装;
但是这也造成很大的困扰,由于 RPM 程序是已经包装好的数据,也就是说, 里面的数据已经都『编译完成』了!所以, 安装的时候一定需要当初安装时的主机环境才能安装 ,也就是说,当初建立这个套件的安装环境必须也要在你的主机上面出现才行!例如 rp-pppoe 这个 ADSL 拨接套件,他必须要在 ppp 这个套件存在的环境下才能进行安装!如果你的主机并没有 ppp 这个套件,那么很抱歉,除非您先安装 ppp 否则 rp-pppoe 就是不让你安装的( 当然您可以强制安装,但是通常都会有点问题发生就是了! )。

所以,通常不同的 distribution 所释出的 RPM 档案,并不能用在其他的 distributions 里面,举例来说, Fedora 释出的 RPM 档案,通常无法直接在 Mandriva 上面进行安装的,更有甚者, 不同版本之间也无法互通,例如 Fedora Core 4 的 RPM 档案就无法直接套用在 FC3 上面!因此,这样可以发现他的缺点是:
  1. 安装的环境必须与打包时的环境需求一致或相当;
  2. 需要满足套件的相依属性需求;
  3. 反安装时需要特别小心,最底层的套件不可先移除,否则可能造成整个系统的问题!
那怎么办?呵呵!还好,还有 SRPM 这个东西! SRPM 是什么呢?顾名思义,他是 Source RPM 的意思,也就是这个 RPM 档案里面含有原始码( Source Code )哩!特别注意的是,这个 SRPM 所提供的套件内容『并没有经过编译』, 他提供的是原始码喔!

通常 SRPM 的扩展名是以 ***.src.rpm 这种格式来命名的 。不过,既然 SRPM 提供的是原始码,那么为什么我们不使用 Tarball 直接来安装就好了?!这是因为 SRPM 虽然内容是原始码, 但是他仍然含有该套件所需要的相依性套件说明、以及所有 RPM 档案所提供的数据,同时,他与 RPM 不同的是,他也提供了参数配置文件( 就是 configure 与 makefile 啦! )。所以,如果我们下载的是 SRPM ,那么要安装该套件时,RPM 套件管理员将会(1)先将该套件以 RPM 管理的方式编译,(2)然后将编译完成的 RPM 档案安装到 Linux 系统当中。与 RPM 档案相比, SRPM 多了一个重新编译的动作, 而且 SRPM 编译完成会产生 RPM 档案

怪了,怎么 SRPM 这么麻烦吶!还要重新编译一次,那么我们直接使用 RPM 来安装不就好了!?通常一个套件在释出的时候,都会同时释出该套件的 RPM 与 SRPM 。我们现在知道 RPM 档案必须要在相同的 Linux 环境下才能够安装,而 SRPM 既然是原始码的格式,自然我们就可以透过修改 SRPM 内的参数配置文件,然后重新编译产生能适合我们 Linux 环境的 RPM 档案,如此一来,不就可以将该套件安装到我们的系统当中,而不必与原作者打包的 Linux 环境相同了?这就是 SRPM 的用处了!


小标题的图示什么是 i386, i586, i686, noarch
好啦!现在我们已经知道 RPM 与 SRPM 的格式了,分别为:
xxxxxxxxx.rpm   <==RPM 的格式,已经经过编译且包装完成的 rpm 档案;
xxxxx.src.rpm   <==SRPM的格式,包含未编译的原始码信息。
那么我们怎么知道这个套件的版本、适用的平台、打包的次数呢?呵呵!只要透过档名就可以知道了!例如 rp-pppoe-3.1-5.i386.rpm 这的档案的意义为:
rp-pppoe -        3.1    -     5        .i386        .rpm
套件名称   套件的版本信息 释出的次数 适合的硬件平台 扩展名
除了后面适合的硬件平台与扩展名外,主要是以『-』来隔开各个部分, 这样子可以很清楚的发现该套件的名称、版本信息、打包次数与操作的硬件平台! 好了,来谈一谈每个不同的地方吧:
  • 套件名称
    当然就是每一个套件的名称了!上面的范例就是 rp-pppoe 。

  • 版本信息
    每一次更新版本就需要有一个版本的信息,否则如何知道这一版是新是旧? 这里通常又分为主版本跟次版本,以上面为例,主版本为 3 ,在主版本的架构下更动部分原始码内容,而释出一个新的版本,就是次版本啦! 以上面为例,就是 1 啰!

  • 释出版本次数
    也就是编译的次数啦!那么为何需要重复的编译呢? 这是由于同一版的套件中,可能由于有某些 bug 或者是安全上的顾虑,所以必须要重新设定当初打包时候的设定参数, 设定完成之后重新编译并打包成 RPM 档案!因此就有不同的打包数出现了!( 注:这个时候原始码其实还是 3.1 那个版本,只是下达编译时的参数不同而已! )

  • 操作硬件平台
    这是个很好玩的地方,由于 RPM 可以适用在不同的操作平台上, 但是由于不同的平台设定的参数还是有所差异性!并且,我们可以针对比较高阶的 CPU 来进行优化参数的设定,所以就有所谓的 i386, i586, i686 与 noarch 等的文件名出现了!

    平台名称适合平台说明
    i386 几乎适用于所有的 x86 平台,不论是旧的 pentum 或者是新的 pentum-IV 与 K7 系列的 CPU等等,都可以正常的工作!那个 i 指的是 Intel 兼容的 CPU 的意思,至于 386 不用说,就是 CPU 的等级啦!
    i586 就是 586 等级的计算机,那是哪些呢?包括 pentum 第一代 MMX CPU, AMD 的 K5, K6 系列 CPU ( socket 7 插脚 ) 等等的 CPU 都算是这个等级;
    i686 在 pentun II 以后的 Intel 系列 CPU ,及 K7 以后等级的 CPU 都属于这个 686 等级!
    noarch 就是没有任何硬件等级上的限制。一般来说,这种类型的 RPM 档案,里面应该没有 binary file 存在。

    需要额外说明的是, i386 的档案可以在任何的机器上面安装, 不论是 586 或者是 686 的机器,但是 i686 则不一定可以使用于 386 或者是 586 的硬件上面,这是因为 i686 的 RPM 档案在编译的时候,主要是针对 686 硬件等级的 CPU 来进行优化编译,而 386/586 等级的硬件可能由于无法支持该优化参数, 所以无法使用呢!另外,在 686 的机器上使用 i686 的档案会比使用 i386 的档案,效能可能比较好一些!无论如何,使用 i386 应该就是比较没有问题的啦!另外,由于不同的 distirbution 会有不同的环境与函式库,所以在 i386 之后也有可能会额外再加上该套件的简写!

小标题的图示RPM 的优点
RPM 有以下的优点:
  • RPM 档案本身为已经编译过的 binary 档案,可以让 client 端的使用者免除重新编译的困扰;
  • RPM 档案在被安装之前,RPM 会先检查系统的硬盘容量、操作系统版本等,可避免档案被安装错误;
  • RPM 档案本身提供套件版本信息、相依属性套件名称、套件用途说明、套件所含档案等信息,便于了解套件;
  • RPM 管理的方式使用数据库记录 RPM 档案的相关参数,便于升级、移除、查询与验证。
为什么 RPM 在使用上很方便呢?我们前面提过, RPM 这个套件管理员所处理的套件,是由套件提供者在特定的 Linux 作业平台上面将该套件编译完成,并且打包好,那使用者只要拿到这个打包好的套件, 然后将里头的档案放置到应该要摆放的目录,不就完成安装啰?!对啦!就是这样! 但是有没有想过,我们在前一章原始码与 Tarball 里面提过的,有些套件是有相关性的,例如要安装网卡驱动程序,就得要有 kernel source 与 gcc 及 make 等套件。那么我们的 RPM 套件是否一定可以安装完成呢?! 如果该套件安装之后,却找不到他相关的前驱套件,那不是挺麻烦的吗?因为安装好的套件也无法使用啊!

为了解决这种具有相关性套件之间的问题,就是所谓的套件相依属性,RPM 就在提供套件打包的档案时,同时加入一些讯息登录的功能,这些讯息包括套件的版本、 打包套件者、相依属性的套件、套件的功能说明、该套件的所有档案与目录纪录、等等,然后在 Linux 系统上面亦建立一个 RPM 套件数据库( database ),如此一来,当您要安装某个以 RPM 型态提供的套件时,在安装的过程中, RPM 会去检验一下数据库里面是否已经存在相关的套件了, 如果数据库显示不存在,那么这个 RPM 档案『预设』就不能安装( 会显示一些错误讯息 )。呵呵!没有错,这个就是 RPM 类型的档案最为人所诟病的『 套件的属性相依』问题啦!


小标题的图示RPM 属性相依的克服方式
虽然 RPM 有套件属性相依的问题,但是 RPM 的优点实在是比缺点要好的多,所以很多使用者还是偏好使用 RPM 来管理自己的套件,在这样的情况下,如何解决 RPM 的属性相依问题呢?最简单的方式就是在安装 RPM 档案的时候,发生套件相依的问题时,手动去下载前驱套件,先安装好这些套件, 然后再安装最终想要安装的套件即可。但是,如此一来很花费使用者的精神与时间,挺麻烦的啦! 有没有比较快速的方法呢?

呵呵!有的,由于 RPM 类型的档案里面含有属性相依的讯息存在,如果我们可以透过分析这些讯息, 再让程序自行去寻找未安装的前驱套件,并事先加以安装,如此一来不就解决了属性相依的困扰了吗?! 没错!是这样!这就是目前所谓的 urpmi/apt/yum 等服务的由来啦!这些服务都是透过分析 RPM 档案的相依信息,然后自行取得相依属性套件, 自行完成安装的动作,呵呵!相当的方便呢!这些信息我们会在 服务器架设篇 里面进行介绍,在这个章节当中,我们主要还是以单纯的 RPM 为主喔!

大标题的图示RPM 套件管理程序
RPM 的使用其实不难,只要使用 rpm 这个指令即可!鸟哥最喜欢的就是 rpm 指令的查询功能了,可以让我很轻易的就知道某个系统有没有安装鸟哥要的套件呢!此外, 我们最好还是得要知道一下,到底 RPM 类型的档案他们是将套件的相关档案放置在哪里呢?还有,我们说的那个 RPM 的数据库又是放置在哪里呢?


小标题的图示RPM 默认安装的路径
一般来说,RPM 类型的档案在安装的时候,会先去读取档案内记载的设定参数内容,然后将该数据用来比对 Linux 系统的环境( 例如属性相依的套件 ),例如目前 SSH 这个远程联机软件( 请参考服务器篇 )使用的是 OpenSSL 的加密机制,所以,要安装 SSH 的时候,就得要先安装好 OpenSSL 才行啊,如果没有安装 OpenSSL 的话, SSH 就不让您安装了!这些都是 RPM 环境的要求, 如果环境相符就予以安装,如果不符就会显示出不符合的内容所在! 等到安装完毕之后, rpm 就会将套件的信息写入:/var/lib/rpm 这个目录中去!所以, 往后您在进行查询的时候或者是预计要升级的时候,相关的信息就会由 /var/lib/rpm 这个目录的内容数据来提供啰!

一般来说,由于 RPM 有数据库来纪录套件相关的信息,所以 RPM 类型的套件所拥有的档案都放置在系统默认放置的目录底下,亦即如同我们在 文件属性与目录配置 一文当中提到的:

/etc 一些配置文件放置的目录,例如 /etc/crontab
/usr/bin 一些可执行文件案
/usr/lib 一些程序使用的动态函式库
/usr/share/doc 一些基本的软件使用手册与说明文件
/usr/share/man 一些 man page 档案

好了,底下我们就来针对每个 RPM 的相关指令来进行说明啰!


小标题的图示RPM 安装( install )
安装就是 install 嘛!所以啰,使用 rpm 来安装就很简单啦!假设我要安装一个档名为 rp-pppoe-3.1-5.i386.rpm 的档案,那么我可以这样( 记得某些套件可能需要以系统管理员的身份来安装 ):
[root@linux ~]# rpm -i rp-pppoe-3.1-5.i386.rpm
不过,这样的参数其实无法显示安装的进度,所以,通常我们会这样下达安装指令:
[root@linux ~]# rpm -ivh package_name
参数:
-i :install 的意思
-v :察看更细部的安装信息画面
-h :以安装信息列显示安装进度
范例:

范例一:安装 rp-pppoe-3.1-5.i386.rpm
[root@linux ~]# rpm -ivh rp-pppoe-3.1-5.i386.rpm
Preparing...     ####################################### [100%]
   1:rp-pppoe    ####################################### [100%] 

范例二、一口气安装两个以上的套件时:
[root@linux ~]# rpm -ivh a.i386.rpm b.i386.rpm *.rpm
# 后面直接接上许多的套件档案!

范例三、直接由网络上面的某个档案安装,以网址来安装:
[root@linux ~]# rpm -ivh http://website.name/path/pkgname.rpm
另外,如果我们在安装的过程当中发现问题,或者已经知道会发生的问题, 而还是『执意』要安装这个套件时,可以使用如下的参数『强制』安装上去:

可下达的参数代表意义
--nodeps 使用时机: 如果您在安装某个套件时,老是发现 rpm 告诉你『有属性相依的套件尚未安装』, 而您又想要直接强制安装这个套件时,可以加上 --nodeps 告知 RPM 不要去检查套件的相依性。
危险性: 套件会有相依性的原因是因为彼此会使用到对方的机制或功能,如果强制安装而不考虑套件的属性相依, 则可能会造成该套件的无法正常使用!
--nomd5 使用时机: 不想检查 RPM 档案所含的 MD5 信息时。
说明: 还记得我们在前一章有提到的 MD5 这个指纹辨识吧?!没错,这里指的就是不要检查 RPM 套件的 MD5 信息。但除非您很清楚这个套件的来源,否则不建议使用这个参数。
--noscripts 使用时机: 不想让该套件自行启用或者自行执行某些系统指令。
说明: RPM 的优点除了可以将档案放置到定位之外,还可以自动执行一些前置作业的指令,例如数据库的初始化。 如果您不想要让 RPM 帮您自动执行这一类型的指令,就加上他吧!
--replacefiles 使用时机: 如果在安装的过程当中出现了『某个档案已经被安装在您的系统上面』的信息, 又或许出现版本不合的讯息( confilcting files )时,可以使用这个参数来直接覆盖档案。
危险性: 覆盖的动作是无法复原的!所以,您必须要很清楚的知道被覆盖的档案是真的不重要喔!否则会欲哭无泪!
--replacepkgs 使用时机: 重新安装某个已经安装过的套件!
--force 使用时机: 这个参数其实就是 --replacefiles 与 --replacepkgs 的综合体!
--test 使用时机: 想要测试一下该套件是否可以被安装到使用者的 Linux 环境当中。范例为:
rpm -ivh pkgname.i386.rpm --test

一般来说,安装的指令大约就是这些了。通常鸟哥建议直接使用 -ivh 就好了, 如果安装的过程中发现问题,一个一个去将问题找出来,尽量不要使用『 暴力安装法 』,因为可能会发生很多不可预期的问题呢! 除非您很清楚的知道使用上面的参数后,安装的结果是您预期的!


小标题的图示RPM 升级与更新
使用 RPM 来升级真是太简单了!就以 -Uvh 或 -Fvh 来升级即可( 注:vh 的功能仍是在于显示细部信息与安装进度而已 )!不过,这两种升级方式是不太一样的:

-Uvh 后面接的套件即使没有安装过,则系统将予以直接安装; 若后面接的套件有安装过旧版,则系统自动更新至新版;
-Fvh 如果后面接的套件并未安装到您的 Linux 系统上,则该套件不会被安装;亦即只有安装至您 Linux 系统内的套件会被『升级』!

由上面的说明来看,如果您想要大量的升级系统旧版本的套件时( 例如刚安装完操作系统,而想要更新套件至最新 ),使用 -Fvh 则是比较好的作法。但是需要注意的是,如果您使用的是 Fvh ,偏偏您的机器上尚无这一个套件,那么很抱歉,该套件并不会被安装在您的 Linux 主机上面,所以请重新以 ivh 来安装吧!

通常有的朋友在进行整个操作系统的旧版套件修补时,喜欢这么进行:
  1. 先到各发展商的 errata 网站或者是国内的 FTP 映像站捉下来最新的 RPM 档案;
  2. 使用 -Fvh 来将您的系统内曾安装过的套件进行修补与升级!(真是方便呀!)
当然啰,升级也是可以利用 --nodeps/--force 等等的参数啦!


小标题的图示RPM 查询
RPM 在查询的时候,其实查询的地方是在 /var/lib/rpm 这个目录下的数据库档案啦!另外, RPM 也可以查询档案内的信息喔!那如何去查询呢?我们底下以 简单的范例来说明:
[root@linux ~]# rpm -qa
[root@linux ~]# rpm -q[licdR] 已安装的套件名称
[root@linux ~]# rpm -qf 存在于系统上面的某个档案
[root@linux ~]# rpm -qp[licdR] 未安装的某个文件名
参数:
在查询的部分,所有的参数之前都需要加上 -q 才是所谓的查询!
查询主要分为两部分,一个是查已安装,另一个则是查某个 rpm 档案内容。
查询已安装套件的信息:
-q  :仅查询,后面接的套件名称是否有安装;
-qa :列出所有的,已经安装在本机 Linux 系统上面的所有套件名称;
-qi :列出该套件的详细信息 (information),包含开发商、版本与说明等;
-ql :列出该套件所有的档案与目录所在完整文件名 (list);
-qc :列出该套件的所有配置文件 (找出在 /etc/ 底下的檔名而已)
-qd :列出该套件的所有说明档 (找出与 man 有关的档案而已)
-qR :列出与该套件有关的相依套件所含的档案 (Required 的意思)
-qf :由后面接的文件名,找出该档案属于哪一个已安装的套件;
查询某个 RPM 档案内含有的信息:
-qp[icdlR]:注意 -qp 后面接的所有参数以上面的说明一致。但用途仅在于找出
	    某个 RPM 档案内的信息,而非已安装的套件信息!注意!
范例:

范例一:找出你的 Linux 是否有安装 logrotate 这个套件?
[root@linux ~]# rpm -q logrotate
logrotate-3.7.1-10
[root@linux ~]# rpm -q logrotating
package logrotating is not installed
# 注意到,系统会去找是否有安装后面接的套件名称。注意,
# 不必要加上版本喔!至于显示的结果,一看就知道有没有安装啦!

范例二:列出上题当中,该套件的所有目录与档案:
[root@linux ~]# rpm -ql logrotate
/etc/cron.daily/logrotate
/etc/logrotate.conf
......以下省略......
# 可以看出该套件到底提供了多少的档案与目录。

范例三:列出 logrotate 这个套件的相关说明资料:
[root@linux ~]# rpm -qi logrotate
Name        : logrotate                Relocations: (not relocatable)
Version     : 3.7.1                         Vendor: Red Hat, Inc.
Release     : 10                        Build Date: Fri Apr  1 03:54:42 2005
Install Date: Sat Jun 25 08:28:26 2005  Build Host: tweety.build.redhat.com
Group       : 系统环境/基础             Source RPM: logrotate-3.7.1-10.src.rpm
Size        : 47825                        License: GPL
Signature   : DSA/SHA1, Sat May 21 01:34:11 2005, Key ID b44269d04f2a6fd2
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Summary     : 循环、压缩、移除以及邮寄系统纪录档案。
Description :
The logrotate utility is designed to simplify the administration of
log files on a system which generates a lot of log files. Logrotate
allows for the automatic rotation, compression, removal, and mailing of
log files. Logrotate can be set to handle a log file daily, weekly,
monthly, or when the log file gets to a certain size. Normally,
logrotate runs as a daily cron job.
# 列出该套件的 information (信息),里面的信息可多着呢,包括了套件名称、
# 版本、开发商、SRPM文件名、打包次数、简单说明信息、套件打包者、
# 安装日期等等!如果想要详细的知道该套件的数据,用这个参数来了解一下

范例四:分别仅找出 logrotate 的配置文件与说明档
[root@linux ~]# rpm -qc logrotate
[root@linux ~]# rpm -qd logrotate

范例五:若要成功安装 logrotate ,他还需要什么档案的帮忙?
[root@linux ~]# rpm -qR logrotate
/bin/sh
config(logrotate) = 3.7.1-10
libc.so.6
....以下省略....
# 由这里看起来,呵呵~还需要很多档案的支持才行喔!

范例六:由上面的范例五,找出 /bin/sh 是那个套件提供的?
[root@linux ~]# rpm -qf /bin/sh
bash-3.0-31
# 这个参数后面接的可是『档案』吶!不像前面都是接套件喔!
# 这个功能在查询系统的某个档案属于哪一个套件所有的。

范例七:假设我有下载一个 RPM 档案,想要知道该档案的需求档案,该如何?
[root@linux ~]# rpm -qpR filename.i386.rpm
# 加上 -qpR ,找出该档案需求的数据!
常见的查询就是这些了!要特别说明的是,在查询本机上面的 RPM 套件相关信息时, 不需要加上版本的名称,只要加上套件名称即可!因为他会由 /var/lib/rpm 这个数据库里面去查询, 所以我们可以不需要加上版本名称。但是查询某个 RPM 档案就不同了, 我们必须要列出整个档案的完整档名才行~ 这一点朋友们常常会搞错。底下我们就来做几个简单的练习吧!

例题:
我想要知道我的系统当中,以 c 开头的套件有几个,如何实做?
    rpm -qa | grep ^c | wc -l
我的 WWW 服务器为 Apache ,我知道他使用的 RPM 套件档名为 httpd 。 现在,我想要知道这个套件的所有配置文件放置在何处,可以怎么作?
    rpm -qc httpd
承上题,如果查出来的配置文件案已经被我改过,但是我忘记了曾经修改过哪些地方, 所以想要直接重新安装一次该套件,该如何作?
    假设该套件在网络上的网址为:
    http://web.site.name/path/httpd-x.x.xx.i386.rpm
    则我可以这样做:
    rpm -ivh http://web.site.name/path/httpd-x.x.xx.i386.rpm --replacepkgs
如果我误砍了某个重要档案,例如 /etc/crontab,偏偏不晓得他属于哪一个套件,该怎么办?!
    虽然已经没有这个档案了,不过没有关系,因为 RPM 有纪录在 /var/lib/rpm 当中的数据库啊!所以直接下达:
    rpm -qf /etc/crontab
    就可以知道是那个套件啰!重新安装一次该套件即可!


小标题的图示RPM 验证与数字签名
验证的功能主要在于提供系统管理员一个有用的管理机制!作用的方式是『 使用 /var/lib/rpm 底下的数据库内容来比对目前 Linux 系统的环境下的所有套件档案 』也就是说,当您有数据不小心遗失, 或者是因为您误杀了某个套件的档案,或者是不小心不知道修改到某一个套件的档案内容, 就用这个简单的方法来验证一下原本的文件系统吧! 好让您了解这一阵子到底是修改到哪些档案数据了!验证的方式很简单:
[root@linux ~]# rpm -Va
[root@linux ~]# rpm -V  已安装的套件名称
[root@linux ~]# rpm -Vp 某个 RPM 档案的档名
[root@linux ~]# rpm -Vf 在系统上面的某个档案
参数:
-V  :后面加的是套件名称,若该套件所含的档案被更动过,才会列出来;
-Va :列出目前系统上面所有可能被更动过的档案;
-Vp :后面加的是文件名,列出该套件内可能被更动过的档案;
-Vf :列出某个档案是否被更动过~
范例:

范例一:列出你的 Linux 内的 logrotate 这个套件是否被更动过?
[root@linux ~]# rpm -V logrotate
# 如果没有出现任何讯息,恭喜你,该套件没有被更动过。
# 如果有出现任何讯息,才是有出现状况啊!

范例二:查询一下,你的 /etc/crontab 是否有被更动过?
[root@linux ~]# rpm -Vf /etc/crontab
S.5....T  c /etc/crontab
# 瞧!因为有被更动过,所以会列出被更动过的信息!
好了,那么我怎么知道到底我的档案被更动过的内容是什么?呵呵!简单的说明一下吧! 例如,我们检查一下 logrotate 这个套件:
[root@linux ~]# rpm -ql logrotate
/etc/cron.daily/logrotate
/etc/logrotate.conf
/etc/logrotate.d
/usr/sbin/logrotate
/usr/share/doc/logrotate-3.7.1
/usr/share/doc/logrotate-3.7.1/CHANGES
/usr/share/man/man8/logrotate.8.gz
/var/lib/logrotate.status
# 呵呵!共有八个档案啊! 

[root@linux ~]# rpm -V logrotate
..5....T c /etc/logrotate.conf
# 上面的信息是这样的:
S :file Size differs
    档案的容量大小是否被改变
M :Mode differs (includes permissions and file type)
    档案的类型或档案的属性,如是否可执行等参数已被改变
5 :MD5 sum differs
    MD5 这一种加密防骇的属性已被改变
D :Device major/minor number mis-match
    装置名称已被改变
L :readLink(2) path mis-match
    Link 属性已被改变
U :User ownership differs
    档案的所属人已被改变
G :Group ownership differs
    档案的所属群组已被改变
T :mTime differs
    档案的建立时间已被改变
所以,如果当一个档案所有的信息都被更动过,那么他的显示就会是:
SM5DLUGT c filename
至于那个 c 代表的是『 Config file 』的意思,也就是档案的类型,文件类型有底下这几类:
  • c :配置文件(config file)
  • d :文件数据文件(documentation)
  • g :鬼档案~通常是该档案不被某个套件所包含,较少发生!(ghost file)
  • l :许可证文件(license file)
  • r :自述文件(read me)
经过验证的功能,您就可以知道那个档案被更动过。那么如果该档案的变更是『预期中的』, 那么就没有什么大问题,但是如果该档案是『非预期的』,那么是否被入侵了呢?呵呵! 得注意注意啰!

再来,由于数字签证的盛行,我们 Linux 的 RPM 也可以利用数字签证来判断待安装的套件档案是否有问题喔!一般我们使用的是 GPG 的密钥( public key )。应用的方法很简单,首先, 当我们想要使用某个团体释出的套件时,就需要将他们释出的 GPG 密钥先安装在自己的 Linux 系统上。然后,当安装该团体释出的套件时,就会检查两者的 key 是否相同,如果相同就直接安装,如果不同就会在屏幕上面显示讯息告知您并未安装该团体的 GPG 密钥!

安装密钥的方法很简单,例如 Red Hat 本身就有密钥在系统当中,安装如下:
[root@linux ~]# rpm --import /usr/share/rhn/RPM-GPG-KEY
一般来说,您的 Linux distributions 都会释出自己的 GPG Key 的,如果是 Red Hat 系统的话, 可以使用:
[root@linux ~]# locate GPG-KEY
来进行搜寻档案的工作,至于这些密钥的内容,我们可以这样查询喔:
[root@linux ~]# rpm -qa | grep gpg
libgpg-error-1.0-2
gpg-pubkey-4f2a6fd2-3f9d9d3b
[root@linux ~]# rpm -qi gpg-pubkey-4f2a6fd2-3f9d9d3b
Name        : gpg-pubkey               Relocations: (not relocatable)
Version     : 4f2a6fd2                      Vendor: (none)
Release     : 3f9d9d3b                  Build Date: Sat Jun 25 22:13:00 2005
Install Date: Sat Jun 25 22:13:00 2005  Build Host: localhost
Group       : Public Keys               Source RPM: (none)
Size        : 0                            License: pubkey
Signature   : (none)
Summary     : gpg(Fedora Project <fedora@redhat.com>)
Description :
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: rpm-4.4.1 (beecrypt-3.0.0)

mQGiBD+dnTsRBACwnlz4AhctOLlVBAsq+RaU82nb5P3bD1YJJpsAce1Ckd2sBUOJD11NUCqH
.....中间省略.....
=mJAx
-----END PGP PUBLIC KEY BLOCK-----
这样就能看到相关的信息啰! ^_^


小标题的图示RPM 反安装与重建数据库
反安装就是将套件卸载啦!要注意的是,『解安装的过程一定要由最上层往下解除』,以 rp-pppoe 为例,这一个套件主要是依据 ppp 这个套件来安装的,所以当您要解除 ppp 的时候,就必须要先解除 rp-pppoe 才行!否则就会发生结构上的问题啦!这个可以由建筑物来说明, 如果你要拆除五、六楼,那么当然要由六楼拆起,否则拆了第五楼,那么上面的楼层难道会悬空?

那么重建数据库呢?由于我们会一直在修改一些档案内容,例如 /etc/xinetd.d 里头的参数档案,加上可能自系统操作的过程中新增、移除等等的动作,导致系统的数据库有点乱, 这个时候可以使用--rebuilddb 来重建一下 rpm 的数据库!这两个方法的参数如下啰:
[root@linux ~]# rpm -e logrotate  <==解安装 logrotate 套件
[root@linux ~]# rpm --rebuilddb   <==重建数据库

大标题的图示SRPM 的使用
谈完了 RPM 类型的套件之后,再来我们谈一谈包含了 Source code 的 SRPM 该如何使用呢?!假如今天我们由网络上面下载了一个 SRPM 的档案,该如何安装他?又,如果我想要修改这个 SRPM 里面原始码的相关设定值,又该如何订正与重新编译呢?!此外,最需要注意的是,新版的 rpm 已经将 RPM 与 SRPM 的指令分开了,SRPM 使用的是 rpmbuild 这个指令,而不是 rpm 喔!如果您是 Red Hat 7.3 以前的用户,那么请使用 rpm 来替代 rpmbuild 啦!


小标题的图示利用系统默认值安装 SRPM 档案
假设我下载了一个 SRPM 的档案,又不想要修订这个档案内的原始码与相关的设定值, 那么我可以直接编译并安装吗?当然可以!利用 rpmbuild 配合参数即可。参数主要有底下两个:

--rebuild 这个参数会将后面的 SRPM 进行『编译』与『打包』的动作,最后会产生 RPM 的档案,但是产生的 RPM 档案并没有安装到系统上。当您使用 --rebuild 的时候,最后通常会发现一行字体:
Wrote: /usr/src/RPM/RPMS/i386/pkgname.i386.rpm
这个就是编译完成的 RPM 档案啰!那么这个档案就可以用来安装啦!安装的时候请加绝对路径来安装即可!
--recompile 这个动作会直接的『编译』『打包』并且『安装』啰!请注意, rebuild 仅『编译并打包』而已,而 recompile 不但进行编译跟打包,还同时进行『安装』了!

一般来说,如果编译的动作顺利的话,那么编译过程所产生的中间暂存档都会被自动删除, 如果发生任何错误,则该中间档案会被保留在系统上,等待用户的除错动作!那么, 该如何除错呢?!如果想要自行除错,就得要知道利用 SRPM 的时候,系统会动用到哪些重要的目录了!底下我们就来谈一谈当处理 SRPM 时,系统会使用到的目录。


小标题的图示SRPM 使用的路径与需要的套件
SRPM 既然含有 source code ,那么其中必定有配置文件啰,所以首先我们必需要知道,这个 SRPM 在进行编译的时候,会使用到哪些目录呢?这样一来才能够来修改嘛!你可以到你的 /usr/src 这个目录里面去查看一下,通常每个 distribution 提供的目录都不太相同,以 FC4 为例,他是以 /usr/src/redhat/ 为工作目录, Openlinux 则是以 /usr/src/openlinux 为工作目录!无论如何,反正就是在 /usr/src 这个目录下就对了!好了到 /usr/src/redhat 里头去看一看呦:

/usr/src/redhat/SPEC 这个目录当中放置的是该套件的配置文件,例如这个套件的信息参数、设定项目等等都放置在这里;
/usr/src/redhat/SOURCE 这个目录当中放置的是该套件的原始档(*.tar.gz的档案)以及 config 这个配置文件;
/usr/src/redhat/BUILD 在编译的过程中,有些暂存的数据都会放置在这个目录当中;
/usr/src/redhat/RPMS 经过编译之后,并且顺利的编译成功之后,将打包完成的档案放置在这个目录当中。里头有包含了 i386, i586, i686, noarch.... 等等的次目录。

此外,在编译的过程当中,可能会发生不明的错误,或者是设定的错误,这个时候就会在 /tmp 底下产生一个相对应的错误档,您可以根据该错误档进行除错的工作呢! 等到所有的问题都解决之后,也编译成功了,那么刚刚解压缩之后的档案,就是在 /usr/src/redhat/SPEC, SOURCE, BUILD 等等的档案都会被杀掉,而只剩下放置在 /usr/src/redhat/RPMS 底下的档案了!

由于 SRPM 需要重新编译,而编译的过程当中,我们至少需要有 make 与其相关的程序,及 gcc, c, c++ 等其他的编译用的程序语言来进行编译,所以, 如果您在安装的过程当中没有选取软件开发工具之类的套件,呵呵!得重新拿出你的光盘, 然后再安装喔!哈哈!只是得要克服一大堆的属性相依的问题就是了~ 嗯!还是建议您再次的看一下如何安装吧!


小标题的图示配置文件的主要内容
刚刚我们在上面提过了,SRPM 还可以更改一些设定的内容,那么要如何修改这些设定的内容呢?我们以简单的 rp-pppoe 这个套件来说明好了。比较可惜的是, rp-pppoe 的官方网站目前 (2005/10) 似乎不再提供新的 SRPM 档案了,所以,我们是由 rpmfind.net ( http://rpmfind.net/ ) 找到给 FC4 使用的 SRPM 档案 (是测试版喔!) , 你可以自行查阅一下这个 rp-pppoe 相关的信息以及 rpmfind.net 网站提供的信息。 至于基本的过程如下:(鸟哥在这里假设你已经将 rp-pppoe-3.5-30.src.rpm 下载到 /root 底下了)
[root@linux ~]# rpm -i /root/rp-pppoe-3.5-30.src.rpm
# 这个过程不会显示任何东西,他只会将 SRPM 的档案解开后,放置到 
# /usr/src/redhat 下!

[root@linux ~]# find /usr/src/redhat/ -type f
/usr/src/redhat/SOURCES/rp-pppoe-3.5-buildroot.patch
/usr/src/redhat/SOURCES/adsl-stop
/usr/src/redhat/SOURCES/adsl-start
/usr/src/redhat/SOURCES/adsl-setup
/usr/src/redhat/SOURCES/rp-pppoe-3.4-redhat.patch
/usr/src/redhat/SOURCES/adsl-status
/usr/src/redhat/SOURCES/rp-pppoe-3.5-firewall.patch
/usr/src/redhat/SOURCES/adsl-connect
/usr/src/redhat/SOURCES/rp-pppoe-3.5.tar.gz
/usr/src/redhat/SPECS/rp-pppoe.spec
# 主要含有原始码与一个重要的配置文件啊! rp-pppoe.spec !
好了,来看看我们的设定参数档,亦即是在 /usr/src/redhat/SPECS 内的 *.spec 档案啰!
[root@linux ~]# cd /usr/src/redhat/SPECS
[root@linux SPECS]# vi rp-pppoe.spec
# 1. 首先,这个部分在介绍整个套件的基本相关信息!不论是版本还是释出次数等。
Summary: A PPP over Ethernet client (for xDSL support).
Name: rp-pppoe
Version: 3.5
Release: 30
License: GPL
Group: System Environment/Daemons
Url: http://www.roaringpenguin.com/pppoe/
Source: http://www.roaringpenguin.com/rp-pppoe-%{version}.tar.gz
Source1: adsl-connect
Source2: adsl-setup
.....中间省略.....

# 2. 这部分则是在设定相依属性需求的地方!
Prereq: /sbin/chkconfig
Prereq: /sbin/service
Prereq: fileutils
Requires: ppp >= 2.4.2
Requires: initscripts >= 5.92
Requires: iproute >= 2.6
ExcludeArch: s390 s390x

%description
PPPoE (Point-to-Point Protocol over Ethernet) is a protocol used by
many ADSL Internet Service Providers. This package contains the
Roaring Penguin PPPoE client, a user-mode program that does not
require any kernel modifications. It is fully compliant with RFC 2516,
the official PPPoE specification.

# 3. 编译前的预处理,以及编译过程当中所需要进行的指令,都写在这里
#    尤其 %build 底下的数据,几乎就是 makefile 里面的信息啊!
%prep
%setup -q
%patch0 -p1 -b .config
%patch1 -p1 -b .buildroot
%patch2 -p1 -b .ipchains

%build
cd src
autoconf
CFLAGS="-D_GNU_SOURCE" %configure
make

install -m 0755 %{SOURCE1} scripts
install -m 0755 %{SOURCE2} scripts
install -m 0755 %{SOURCE3} scripts
install -m 0755 %{SOURCE4} scripts
install -m 0755 %{SOURCE5} scripts

%install
rm -rf $RPM_BUILD_ROOT
.....中间省略.....

# 4. 这里列出,这个套件释出的档案有哪些的意思!
%files
%defattr(-,root,root)
%doc doc/LICENSE scripts/adsl-connect scripts/adsl-setup scripts/adsl-init
%doc scripts/adsl-start scripts/adsl-status scripts/adsl-stop
%doc configs
%config(noreplace) %{_sysconfdir}/ppp/pppoe-server-options
%config(noreplace) %{_sysconfdir}/ppp/firewall*
/sbin/*
%{_sbindir}/*
%{_mandir}/man?/*

# 5. 列出这个套件的更改历史纪录文件!
%changelog
* Mon Aug 15 2005 Than Ngo <than@redhat.com> 3.5-30
- defaultroute should not overridden #152014
.....中间省略.....
* Wed May 31 2000 Than Ngo <than@redhat.de>
- adopted for Winston.
注意到的是rp-pppoe.sepc这个档案,这是主要的将SRPM编译成RPM的配置文件,他的基本规则可以这样看:
  1. 整个档案的开头以Summary为开始,这部份的设定都是最基础的说明内容;
  2. 然后每个不同的段落之间,都以%来做为开头,例如%prep与%install等;
我们来谈一谈几个常见的SRPM设定段落:

  • 系统整体信息方面:
  • Summary 主要的套件说明,例如上表中,我们说明了他是 ppp 的拨接用途啦!
    Name 这个就是套件的名称;
    Version 这个是套件的版本信息;
    Release 这个是该版本打包的次数说明;
    License 这个套件的授权模式,我们是使用 GPL 啦!
    Group 这个套件的发展团体名称;
    Source 这个套件的来源,如果是网络上下载的套件,通常一定会有这个信息来告诉大家这个原始档的来源!
    Url 这个原始码的主要官方网站;
    Packager 这个套件是经由谁来打包的呢?
    Vender 发展的厂商哪;
    ExclusiveArch 这个是说明这个套件的适合安装的硬件,通常默认为 i386,当然,你也可以调整为 i586 啦等等的!
    Requires 如果你这个套件还需要其他的套件的支持,那么这里就必需写上来,则当你制作成 RPM 之后,系统就会自动的去检查啦!这就是『相依属性』的主要来源啰!

    上面几个资料通常都必需要写啦!但是如果你的软件没有相依属性的关系时, 那么就可以不需要那个Requires啰!
  • %description
  • 将您的套件做一个简短的说明!这个也是必需要的。
  • %prep
  • 这部份的设定在于『尚未进行设定或安装之前,你要编译完成的 RPM 帮你事先做的事情』,就是 prepare 的简写啰!那么他的工作事项主要有:
    1. 寻找套件所需要的目录是否已经存在?确认用的!
    2. 事先建立您的套件所需要的目录,或者事先需要进行的任务;
    3. 如果待安装的Linux系统内已经有安装的时候可能会被覆盖掉的档案时, 那么就必需要进行备份(backup)的工作了!
    大致的工作就是这些啦!
  • %setup
  • 这个段落就是在建立我们在 Tarball 当中说明的那个 Makefile 档案啦!所以呢,当然就是执行 ./config 之类的配置文件案啰! 那么如果你要自己新增自己的参数,就可以在这个地方加入你的设定值! 如果你的软件本身没有这方面的需要,里面就不需要编写内容啰!
  • %build
  • build 就是建立啊!所以当然啰,这个段落就是在谈怎么 make 编译成为可执行的程序啰!
  • %install
  • 编译完成 (build) 之后,就是要安装啦!安装就是写在这里,也就是类似 Tarball 里面的 make install的意思啰!
  • %files
  • 这个套件安装的档案都需要写到这里来,当然包括了『目录』喔! 所以连同目录请一起写到这个段落当中!以备查验呢!^_^
  • %changelog
  • 这个主要则是在记录这个套件曾经的更新纪录啰!
    好了,那么如果您有自定义的信息想要加入的话,就选择你要加入的那个段落,将他修改一下吧! 例如,如果你在设定 Makefile 的时候,希望能够多一些额外的参数设定,那么就找到 %setup 或 %build 那个段落,将他修改成您所需要的样子,就可以啰!


    小标题的图示SRPM 的编译指令
    再来呢?嗯!没错,修改完成了,自然就是要将他编译成可以安装的 RPM 档案啦! 这个时候我们就可以直接在 /usr/src/redhat/SPECS 底下下达:
    [root@linux ~]# rpmbuild -bb rp-pppoe.spec  <==编译成RPM档案
    [root@linux ~]# rpmbuild -ba rp-pppoe.spec  <==打包成SRPM档案
    
    这个时候系统就会这样做:
    1. 先进入到 BUILD 这个目录中,在 Fedora 底下就是 /usr/src/redhat/BUILD 这个目录;
    2. 依照 *.spec 档案内的 Name 与 Version 设定定义出工作的目录名称, 以我们上面的例子为例,那么系统就会在 BUILD 目录中先删除 rp-pppoe-3.5 的目录,再重新建立一个 rp-pppoe-3.5 的目录,并进入该目录;
    3. 在新建的目录里面,针对 SOURCES 目录下的来源档案,也就是 *.spec 里面的 Source 设定的那个档案,以 tar 进行解压缩,以我们这个例子来说,则会在 /usr/src/redhat/BUILD/rp-pppoe-3.5 当中,将 /usr/src/redhat/SOURCES/rp-pppoe-3.5.tar.gz 进行解压缩啦!
    4. 然后就开始 %setup 的工作;
    5. 再来开始 %build 及 %install 的设定与编译!
    6. 最后将完成打包的档案给他放置到该放置的地方去,如果你的规定的硬件是在i386的系统,那么最后编译成功的*.i386.rpm 档案就会被放置在/usr/src/RPM/RPMS/i386里面啰!如果是i586那么自然就是 /usr/src/redhat/RPMS/i586目录下啰!
    整个步骤大概就是这样子!最后的结果数据会放置在RPMS那个目录底下就对啦!

    大标题的图示一个打包自己套件的范例
    这个就有趣了!我们自己来编辑一下自己制作的 RPM 怎么样?会很难吗?完全不会! 这里简单的以一个小例子来说明喔!请注意,这个真的只是一个小例子,所以不要觉得奇怪喔! 其中,比较需要注意的,由于在上面的步骤说明中,我们知道在将 SRPM 编译成为RPM的时候,会以 tar 这支程序来将档案解开,因此,我们在进行来源档案的建立时, 就必需要将他打包成为一个 tar.gz 的 tarball 的档案才行

    假设我们编辑了一支script,内容是这样:
    [root@linux ~]# cd /usr/src/redhat/SOURCES
    [root@linux SOURCES]# vi showvbird.sh
    #!/bin/bash
    # This file is just used to demo the RPM packaging.
    # the only thing is showing the hostname.
    HOST=`/bin/hostname`
    /bin/echo $HOST
    # 先随便建立一个 shell script ,这个是自己的套件的意思啦!
    
    [root@linux SOURCES]# chmod 755 showvbird.sh
    [root@linux SOURCES]# tar -zcvf showvbird.tar.gz showvbird.sh
    # 注意喔!务必打包才行啊!
    
    上面的动作中,我们编辑了一个 shell script 档案,档名为 showvbird.sh,并且将他打包成为具有 gzip 压缩的 tarball 档案,也就是 showvbird.tar.gz 这样的档案才行!请注意,这个 showvbird.tar.gz 档案『必需』放置在 SOURCES 目录之下!

    再来则是要编辑那个很重要的 *.spec 档案啰!你可以这样简单的编写一下:
    [root@linux SOURCE]# cd /usr/src/redhat/SPECS
    [root@linux SPECS]# vi showvbird.spec
    Summary:   This is a demo RPM package.
    Name:      showvbird
    Version:   1.0
    Release:   1
    License:   GPL
    Group:     VBird's Home
    Source:    showvbird.tar.gz   <==记得喔!这里写的是刚刚建立的 tarball
    Url:       http://linux.vbird.org
    Packager:  VBird
    
    %description
    This package is just a demo RPM.
    
    %prep
    %setup -c
    %install
    install -m 755 showvbird.sh /usr/local/bin/showvbird.sh
    
    %files
    /usr/local/bin/showvbird.sh
    
    好了!开始给他编译并打包成为 RPM 档案啦!
    [root@linux SPECS]# rpmbuild -bb showvbird.spec
    .....中间省略......
    Requires: /bin/bash
    Checking for unpackaged file(s): /usr/lib/rpm/check-files %{buildroot}
    Wrote: /usr/src/redhat/RPMS/i386/showvbird-1.0-1.i386.rpm
    
    最后这个被打包成功的档案就被放置在 /usr/src/redhat/RPMS/i386/showvbird-1.0-1.i386.rpm 啰!然后给他安装一下:
    [root@linux SPECS]# rpm -ivh ../RPMS/i386/showvbird-1.0-1.i386.rpm
    Preparing...                ########################################### [100%]
       1:showvbird              ########################################### [100%]
    
    [root@linux SPECS]# rpm -qi showvbird
    Name        : showvbird                Relocations: (not relocatable)
    Version     : 1.0                           Vendor: (none)
    Release     : 1                         Build Date: Mon Oct  3 11:08:30 2005
    Install Date: Mon Oct  3 11:11:30 2005  Build Host: linux.site.tw
    Group       : VBird's Home              Source RPM: showvbird-1.0-1.src.rpm
    Size        : 143                          License: GPL
    Signature   : (none)
    Packager    : VBird
    URL         : http://linux.vbird.org
    Summary     : This is a demo RPM package.
    Description :
    This package is just a demo RPM.
    
    [root@linux SPECS]# which showvbird.sh
    /usr/local/bin/showvbird.sh
    [root@linux SPECS]# rpm -ql showvbird
    /usr/local/bin/showvbird.sh  <==果然记录起来了!自己的软件呢!
    
    用很简单的方式,就可以将自己的软件或者程序给他修改与设定妥当!很不错吧! 以后您就可以自行设定你的 RPM 啰!当然,也可以手动修改您的 SRPM 的来源档内容啰!


    大标题的图示要选择 RPM 还是 Tarball?
  • 优先选择 RPM:
  • 这一直是个有趣的问题:『如果我要升级的话,或者是全新安装一个新的套件, 那么该选择 RPM 还是 Tarball 来安装呢?』!基本上,如果有 RPM 可以提供给您的 distribution 来安装,并且没有严重的相依属性的问题时,呵呵!选择 RPM 来安装会是一个比较好的解决方案, Why ?这是由于刚刚上面就提到的 RPM 的好处 啦!可以具有档案与数据均有纪录的优点,这就是上面提到的 /var/lib/rpm 这个目录里面的数据库,这个记录可以让你在管理上更为便利,包括上面提到的 RPM 的升级、安装、验证与移除等等。尤其是在查询上面!可以让你在管理你的系统上面更为便利。

    但是 RPM 也不是没有缺点的,包括最为大家所抱怨连连的『 属性相依 』的问题,每一个不同版本之间,就必须要以不同的 RPM 档案来安装!此外,如果要升级『某一个套件』而已时, 通常还需要连带其他的套件也必须要一起升级才行,否则会有问题!此外,当一个套件经过了『 大幅度的修改 』之后,通常旧的 RPM 与新的 RPM 之间已经几乎无法『完全兼容』时, 呵呵!那么升级或者是移除的手续可是会累坏人的!

    例如前两年朋友们常常问到的 Apache 1.3.xx 与 2.0.xx 的版本升级问题! 由于这两个版本之间的架构差异性太大,加上版本属性相依问题,所以很难得到一个完满的解决方案,这个时候 RPM 就不那么合适了。( 除非您要一个一个的将 Apache 移除,连同其相依的套件,然后再将 Apache 一个一个的安装,包括新套件的相依套件! ^_^ .....鸟哥是不会这么做的啦! )

  • 简易方法:
  • 如果 RPM 档案并不是这么容易取得的话,这个时候 Tarball 的方式就特别适合您的安装了!这是因为 Tarball 可以自行设定编译时的参数,此外,也可以自行设定『安装路径』, 相当的适合于想要安装『多个不同版本的同一个套件』的情况( 说穿了就是测试机器 )!

    这是怎么说呢?!由于 RPM 必须要配合系统里面其他的相依属性的套件,所以基本上, 他的安装路径( 就是每个档案的放置路径 )理论上是必须要放在固定的目录的,就是不能随意的改变他的安装路径。 因此,当有两个不同版本的相同套件想要测试的时候,大概一定就得将原先的版本移除之后, 才能安装使用新的版本啰!(此外,由于相依的套件几乎都已经包含在 tarball 当中了,所以安装上面其实并不难啦!)

    相对于 RPM 的制式格式, tarball 可就灵活多了!你可以自行编译套件并且将他安装在不同的路径, 只要在启动的时候选择正确的版本,那么不同版本的套件可以同时的存在于一个系统当中, 而且可以透过选择启动的档案来启动不同的版本。当然啰!你也可以让 tarball 的安装与 RPM 的安装同时存在于一个系统当中,但是需要特别留意的是, 你在启动该套件的时候,千万记得你的启动路径!免得启动到了错误的版本了!呵呵!( 这也是一个系统存在不同多个版本的套件容易发生的错误! 希望大家都能够了解这个问题呢! )

    所以说,为了避免这种路径上的错误困扰,基本上,我们都希望 Tarball 的安装路径可以设定在 Linux 原本就规划要给大家安装的路径『 /usr/local 』这个路径下!这样可以省去相当多寻找档案的时间! 而且在管理上面也会比较容易!呵呵!

    不过, Tarball 最麻烦的地方有几点:
    • 反安装:
      Tarball 最麻烦的地方就在于他的『解安装』了! 相当的讨厌!如果是简单的直接将所有的套件安装在一个目录下的话,例如 /usr/local/mrtg 时,那么解安装还算简单,就是将该路径杀掉就 OK 啦!但是如果是类似 sendmail 这一种呢?他的路径都是已经放置死的( 需要在 /etc/sendmail.cf、/etc/mail 底下 )那么追踪反安装的路径就很烦人;

    • 在线查询:
      如果您的安装路径是在 /usr/local 底下的话,那么执行档会被放置到 /usr/local/bin ,或者是 /usr/local/sbin 底下,参数档会放在 /usr/local/etc 底下,在线查询档案会放在 /usr/local/man 底下,所以在设定上面还有查询上面还算简单( 路径设定一下即可! ),不过,如果你是将套件安装在单独的路径下呢?例如 /usr/local/mrtg 底下,那么执行档变成了 /usr/local/mrtg/bin 底下,最麻烦的地方就是 man page ( 在线查询 )放置的地点会变成在 /usr/local/mrtg/man 底下了!糟糕!那么默认的 man page 路径就找不到该说明文件啰! 这个时候就必须要手动的将该路径加入 /etc/man.conf 这个档案中!而且执行文件放置的路径也没有指定,可以经由 (1)Link 的方式或者 (2)设定 PATH 环境变量的方式将该路径加进去啦!确实是比较麻烦的啦!
    所以说,RPM 与 Tarball 各有其优缺点,不过,如果有 RPM 的话,那么优先权还是在于 RPM 安装上面,毕竟管理上比较便利,但是如果套件的架构差异性太大, 或者是无法解决相依属性的问题,那么与其花大把的时间与精力在解决属性相依的问题上,还不如直接以 tarball 来安装,轻松又惬意!

    大标题的图示重点回顾
    • RPM 的全名是 Red Hat Package Manager,原本是由 Red Hat 公司所发展的,流传甚广;
    • RPM 类型的套件中,所含有的套件是经过编译后的 binary file ,所以可以直接安装在使用者端( Client )的系统上,不过,也由于如此,所以 RPM 对于安装者的环境要求相当严格;
    • RPM 除了将套件安装至用户的系统上之外,还会将该套件的版本、名称、档案与目录配置、系统需求等等均记录于数据库( /var/lib/rpm )当中,方便未来的查询与升级、移除;
    • RPM 可针对不同的硬件等级来加以编译,制作出来的档案可于扩展名( i386, i586, i686 )来分辨;
    • RPM 最大的问题为套件之间的相依性问题;
    • SRPM 为 Source RPM ,内含的档案为 Source code 而非为 binary file ,所以安装 SRPM 时还需要经过 compile ,不过,SRPM 最大的优点就是可以让使用者自行修改设定参数( makefile/configure 的参数 ),以符合使用者自己的 Linux 环境;

    大标题的图示参考资源
    刚刚最前面说过了,套件升级最主要的考虑就是『安全性』啦!所以请随时注意安全性方面的问题! 目前国内的主要安全网站为:『台湾网络危机处理小组』这个组织,请随时注意上面发布的新闻!另外, 如果跟鸟哥一样使用的是 Red Hat 的 distrubution 的话,那么 Red Hat 的 Errata 网页则不可不光临!好啦!底下列出几个 RPM 相关的网页与 Red Hat 的 Errata 网页提供大家参考啰!

    大标题的图示课后练习
    • 简单说明 RPM 与 SRPM 的异同?
    • RPM 档案是由程序打包者 (通常是由 distribution 的开发商) 藉由程序的原始码,在特定的平台上面所编译成功的 binary program 的数据,并将该数据制作成为 RPM 的格式,以方便相同软、硬件平台的用户之安装使用。 在安装时显的很简单,因为程序打包者的平台与使用者所使用的平台预设为相同。
      至于 SRPM 则是藉由与 RPM 相同的配置文件数据,不过将原始码直接包在 SRPM 档案当中,而不经过编译。 因为 SRPM 所内含的数据为原始码,所以安装时必须要再经过编译的行为才能成为 RPM 并提供使用者安装。
    • 查询系统上的 RPM 套件数据时,系统由何处取得该套件的讯息?
    • 在 /var/lib/rpm/* 当中的数据库档案所取得。
    • 假设我想要安装一个套件,例如 pkgname.i386.rpm ,但却老是发生无法安装的问题,请问我可以加入哪些参数来强制安装他?
    • 可以加入 --nodeps 等参数。例如 rpm -ivh --nodeps pkgname.i386.rpm
    • 承上题,您认为强制安装之后,该套件是否可以正常执行?为什么?
    • 一般来说,应该是『不能执行』的,因为该软件具有相依属性的问题, 某些时刻该软件的程序可能需要呼叫外部的函式库,但函式库可能未安装,因此当然无法执行成功。
    • 有些人使用 OpenLinux 3.1 Server 安装在自己的 P-166 MMX ,却发现无法安装, 在查询了该原版光盘的内容,发现里面的文件名为 ***.i686.rpm 。请问,无法安装的可能原因为何?
    • 因为 P-166MMX 为 i586 的硬件平台,而 OpenLinux 为针对 i686 的硬件平台进行优化, 因此很可能由于下达的参数无法支持的问题,导致无法安装成功。
    • 请问我使用 rpm -Fvh *.rpm 及 rpm -Uvh *.rpm 来升级时,两者有何不同?
    • -Uvh 后面接的软件,如果原本未安装,则直接安装,原本已安装时,则直接升级;
      -Fvh 后面接的软件,如果原本未安装,则不安装,原本已安装时,则直接升级;

    2002/08/21:第一次完成
    2003/02/11:重新编排与加入 FAQ
    2004/04/11:已经完成了 Source code 与 Tarball ,开始进行 RPM 与 SRPM 的介绍!(需要耗时多日啊!因为又要进兵营去了!)
    2004/04/20:终于给他熬出来啦!又是过了两个休假期间~啊!给我退伍令、其余免谈!
    2005/10/02:旧版的 SRPM 数据已经移动到 此处
    2005/10/03:旧版的针对 Red Hat 与 Mandriva 的版本移动到 此处
    2005/10/03:将原本去年的版本改为 FC4 为范例的模样!
     
         
    http://linux.vbird.org is designed by VBird during 2001-2011. ksu.edu 

    本网页主要以Firefox配合解析度 1024x768 作为设计依据     鸟哥自由软件整合应用研究室