Linux学习-软件管理员简介

Linux 界的两大主流: RPM 与 DPKG

目前在 Linux 界软件安装方式最常见的有两种，分别是:

dpkg:

这个机制最早是由 Debian Linux 社群所开发出来的，透过 dpkg 的机制， Debian 提供的软件就能够简单的安装起来，同时还能提供安装后的软件信息，实在非常不错。只要是衍生于 Debian 的其他 Linux distributions 大多使用 dpkg 这个机制来管理软件的，包括 B2D, Ubuntu 等等。

RPM:

这个机制最早是由 Red Hat 这家公司开发出来的，后来实在很好用，因此很多 distributions 就使用这个机制来作为软件安装的管理方式。包括 Fedora, CentOS, SuSE 等等知名的开发商都是用这咚咚。

在 dpkg 管理机制上就开发出 APT 的在线升级机制，RPM 则依开发商的不同，有 Red Hat 系统的 yum ， SuSE 系统的 Yast Online Update (YOU) 等。

distribution 代表	软件管理机制	使用指令	在线升级机制(指令)
Red Hat/Fedora	RPM	rpm, rpmbuild	YUM (yum)
Debian/Ubuntu	DPKG	dpkg	APT (apt-get)

什么是 RPM 与 SRPM

RPM 全名是『 RedHat Package Manager 』简称则为 RPM 。顾名思义，当初这个软件管理的机制是由 Red Hat 这家公司发展出来的。 RPM 是以一种数据库记录的方式来将你所需要的软件安装到你的 Linux 系统的一套管理机制。

他最大的特点就是将你要安装的软件先编译过，并且打包成为 RPM 机制的包装文件，透过包装好的软件里头默认的数据库记录，记录这个软件要安装的时候必须具备的相依属性软件，当安装在你的 Linux 主机时， RPM 会先依照软件里头的数据查询 Linux 主机的相依属性软件是否满足，若满足则予以安装，若不满足则不予安装。那么安装的时候就将该软件的信息整个写入 RPM 的数据库中，以便未来的查询、验证与反安装!这样一来的优点是:

由于已经编译完成并且打包完毕，所以软件传输与安装上很方便 (不需要再重新编译);
由于软件的信息都已经记录在 Linux 主机的数据库上，很方便查询、升级与反安装

通常不同的 distribution 所释出的 RPM 文件，并不能用在其他的 distributions 上。举例来说， Red Hat 释出的 RPM 文件，通常无法直接在 SuSE 上面进行安装的。这样可以发现这些软件管理机制的问题是:

软件文件安装的环境必须与打包时的环境需求一致或相当;
需要满足软件的相依属性需求;
反安装时需要特别小心，最底层的软件不可先移除，否则可能造成整个系统的问题!

SRPM 是什么呢?顾名思义，他是 Source RPM 的意思，也就是这个 RPM 文件里面含有原始码。特别注意的是，这个 SRPM 所提供的软件内容『并没有经过编译』，它提供的是原始码喔!

通常 SRPM 的扩展名是以 ***.src.rpm 这种格式来命名的。不过，既然 SRPM 提供的是原始码，那么为什么我们不使用 Tarball 直接来安装就好了?这是因为 SRPM 虽然内容是原始码，但是他仍然含有该软件所需要的相依性软件说明、以及所有 RPM 文件所提供的数据。同时，他与 RPM 不同的是，他也提供了参数配置文件 (就是 configure 与 makefile)。所以，如果我们下载的是 SRPM ，那么要安装该软件时，你就必须要:

先将该软件以 RPM 管理的方式编译，此时 SRPM 会被编译成为 RPM 文件;
然后将编译完成的 RPM 文件安装到 Linux 系统当中

RPM 文件必须要在相同的 Linux 环境下才能够安装，而 SRPM 既然是原始码的格式，自然我们就可以透过修改 SRPM 内的参数配置文件，然后重新编译产生能适合我们 Linux 环境的 RPM 文件，如此一来，不就可以将该软件安装到我们的系统当中，而不必与原作者打包的 Linux 环境相同了?这就是 SRPM 的用处了!

文件格式	檔名格式	直接安装与否	内含程序类型	可否修改参数并编译
RPM	xxx.rpm	可	已编译	不可
SRPM	xxx.src.rpm	不可	未编译之原始码	可

什么是 i386, i586, i686, noarch, x86_64

从上面的说明，现在我们知道 RPM 与 SRPM 的格式分别为:

xxxxxxxxx.rpm <==RPM 的格式，已经经过编译且包装完成的 rpm 文件;

xxxxx.src.rpm <==SRPM 的格式，包含未编译的原始码信息。

那么我们怎么知道这个软件的版本、适用的平台、编译释出的次数呢?只要透过档名就可以知道了! 例如 rp-pppoe-3.11-5.el7.x86_64.rpm 这的文件的意义为:

rp-pppoe - 3.11 - 5 .el7.x86_64 .rpm

软件名称 软件的版本信息 释出的次数 适合的硬件平台 扩展名

除了后面适合的硬件平台与扩展名外，主要是以『-』来隔开各个部分，这样子可以很清楚的发现该软件的名称、版本信息、打包次数与操作的硬件平台!好了，来谈一谈每个不同的地方吧:

软件名称:

当然就是每一个软件的名称了!上面的范例就是 rp-pppoe 。

版本信息:

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

释出版本次数:

通常就是编译的次数啦!那么为何需要重复的编译呢?这是由于同一版的软件中，可能由于有某些 bug 或者是安全上的顾虑，所以必须要进行小幅度的 patch 或重设一些编译参数。设定完成之后重新编译并打包成 RPM 文件!因此就有不同的打包数出现了!

操作硬件平台:

由于 RPM 可以适用在不同的操作平台上，但是不同的平台设定的参数还是有所差异性! 并且，我们可以针对比较高阶的 CPU 来进行优化参数的设定，这样才能够使用高阶 CPU 所带来的硬件加速功能。所以就有所谓的 i386, i586, i686, x86_64 与 noarch 等的文件名出现了!

平台名称	适合平台说明
i386	几乎适用于所有的 x86 平台，不论是旧的 pentum 或者是新的 Intel Core 2 与 K8 系列的 CPU 等等，都可以正常的工作!那个 i 指的是 Intel 兼容的 CPU 的意思，至于 386 不用说，就是 CPU 的等级啦!
i586	就是针对 586 等级的计算机进行优化编译。那是哪些 CPU 呢?包括 pentum 第一代 MMX CPU， AMD 的 K5, K6 系列 CPU (socket 7 插脚) 等等的 CPU 都算是这个等级;
i686	在 pentun II 以后的 Intel 系列 CPU ，及 K7 以后等级的 CPU 都属于这个 686 等级! 由于目前市面上几乎仅剩 P-II 以后等级的硬件平台，因此很多 distributions 都直接释出这种等级的 RPM 文件。
x86_64	针对 64 位的 CPU 进行优化编译设定，包括 Intel 的 Core 2 以上等级 CPU ，以及 AMD 的Athlon64 以后等级的 CPU ，都属于这一类型的硬件平台。
noarch	就是没有任何硬件等级上的限制。一般来说，这种类型的 RPM 文件，里面应该没有 binary program 存在，较常出现的就是属于 shell script 方面的软件。

RPM 的优点

由于 RPM 是透过预先编译并打包成为 RPM 文件格式后，再加以安装的一种方式，并且还能够进行数据库的记载。所以 RPM 有以下的优点:

RPM 内含已经编译过的程序与配置文件等数据，可以让用户免除重新编译的困扰;
RPM 在被安装之前，会先检查系统的硬盘容量、操作系统版本等，可避免文件被错误安装;
RPM 文件本身提供软件版本信息、相依属性软件名称、软件用途说明、软件所含文件等信息，便于了解软件;
RPM 管理的方式使用数据库记录 RPM 文件的相关参数，便于升级、移除、查询与验证。

为什么 RPM 在使用上很方便呢?我们前面提过， RPM 这个软件管理员所处理的软件，是由软件提供者在特定的 Linux 作业平台上面将该软件编译完成并且打包好。那使用者只要拿到这个打包好的软件，然后将里头的文件放置到应该要摆放的目录，不就完成安装啰?

有些软件是有相关性的，例如要安装网卡驱动程序，就得要有 kernel source 与 gcc 及 make 等软件。那么我们的 RPM 软件是否一定可以安装完成呢?如果该软件安装之后，却找不到他相关的前驱软件，那不是挺麻烦的吗?因为安装好的软件也无法使用啊!

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

RPM 属性相依的克服方式: YUM 在线升级

为了重复利用既有的软件功能，因此很多软件都会以函式库的方式释出部分功能，以方便其他软件的呼叫应用。

因为有上述的现象，因此 RPM 软件文件就会有所谓的属性相依的问题产生。那有没有办法解决啊?前面不是谈到 RPM 软件文件内部会记录相依属性的数据吗?那想一想，要是我将这些相依属性的软件先列表，在有要安装软件需求的时候，先到这个列表去找，同时与系统内已安装的软件相比较，没安装到的相依软件就一口气同时安装起来，那不就解决了相依属性的问题了吗?有没有这种机制啊?有啊!那就是 YUM 机制的由来!

CentOS(1)先将释出的软件放置到 YUM 服务器内，然后(2)分析这些软件的相依属性问题，将软件内的记录信息写下来 (header)。然后再将这些信息分析后记录成软件相关性的列表列表。这些列表数据与软件所在的本机或网络位置可以称呼为容器或软件仓库或软件库 (repository)。当客户端有软件安装的需求时，客户端主机会主动的向网络上面的 yum 服务器的软件库网址下载清单列表，然后透过列表列表的数据与本机 RPM 数据库已存在的软件数据相比较，就能够一口气安装所有需要的具有相依属性的软件了。整个流程可以简单的如下图说明: