linux（Centos）下软件安装的方式总结

　　本文整理摘录自：鸟哥的linux私房菜基础篇之第二十二，二十三章；转载请注明来源：http://www.cnblogs.com/beanmoon/archive/2012/10/30/2746103.html

　　linux下安装及卸载软件是比较头疼的事，不想windows下那样方便，总的来说有以下几种：

　　1. tarball

　　所谓的 Tarball 文件，其实就是将软件的所有原始码文件先以 tar 打包，然后再以压缩技术来压缩，通常最常见的就是以gzip 来压缩了。因为利用了 tar 与 gzip 的功能，所以 tarball 文件一般的扩展名就会写成 *.tar.gz 或者是简写为 *.tgz 罗！不过，近来由於 bzip2 的压缩率较佳，所以 Tarball 渐渐的以 bzip2 的压缩技术来取代 gzip 罗！因此档名也会变成 *.tar.bz2 之类的哩。所以说， Tarball 是一个软件包， 你将他解压缩之后，里面的文件通常就会有：

• 原始程序码文件；
• 侦测程序文件 (可能是 configure 或 config 等档名)；
• 本软件的简易说明与安装说明 (INSTALL 或 README)。

　　其中最重要的是那个 INSTALL 或者是 README 这两个文件，通常你只要能够参考这两个文件， Tarball 软件的安装是很简单的啦！

　　OK！我们底下约略提一下大部分的 tarball 软件之安装的命令下达方式：

1. ./configure
   这个步骤就是在创建 Makefile 这个文件罗！通常程序开发者会写一支 scripts 来检查你的 Linux 系统、相关的软件属性等等，这个步骤相当的重要， 因为未来你的安装资讯都是这一步骤内完成的！另外，这个步骤的相关资讯应该要参考一下该目录下的 README 或 INSTALL 相关的文件！
2. make clean
   make 会读取 Makefile 中关於 clean 的工作。这个步骤不一定会有，但是希望运行一下，因为他可以去除目标文件！因为谁也不确定原始码里面到底有没有包含上次编译过的目标文件 (*.o) 存在，所以当然还是清除一下比较妥当的。 至少等一下新编译出来的运行档我们可以确定是使用自己的机器所编译完成的嘛！
3. make
   make 会依据 Makefile 当中的默认工作进行编译的行为！编译的工作主要是进行 gcc 来将原始码编译成为可以被运行的 object files ，但是这些 object files 通常还需要一些函式库之类的 link 后，才能产生一个完整的运行档！使用 make 就是要将原始码编译成为可以被运行的可运行档，而这个可运行档会放置在目前所在的目录之下， 尚未被安装到预定安装的目录中；
4. make install
   通常这就是最后的安装步骤了，make 会依据 Makefile 这个文件里面关於 install 的项目，将上一个步骤所编译完成的数据给他安装到预定的目录中，就完成安装

　　让我们先来看一看 Linux distribution 默认的安装软件的路径会用到哪些？我们以 apache 这个软件来说明的话：

• /etc/httpd
• /usr/lib
• /usr/bin
• /usr/share/man

　　我们会发现软件的内容大致上是摆在 etc, lib, bin, man 等目录当中，分别代表『配置档、函式库、运行档、线上说明档』。 好了，那么你是以 tarball 来安装时呢？如果是放在默认的 /usr/local 里面，由於 /usr/local 原本就默认这几个目录了，所以你的数据就会被放在：

• /usr/local/etc
• /usr/local/bin
• /usr/local/lib
• /usr/local/man

　　但是如果你每个软件都选择在这个默认的路径下安装的话， 那么所有的软件的文件都将放置在这四个目录当中，因此，如果你都安装在这个目录下的话， 那么未来再想要升级或移除的时候，就会比较难以追查文件的来源罗！ 而如果你在安装的时候选择的是单独的目录，例如我将 apache 安装在 /usr/local/apache 当中（可以通过这种方式设置：./configure --prefix=/usr/local/apche --enable-all-clocks --enable-parse-clocks），那么你的文件目录就会变成：

• /usr/local/apache/etc
• /usr/local/apache/bin
• /usr/local/apache/lib
• /usr/local/apache/man

　　呵呵！单一软件的文件都在同一个目录之下，那么要移除该软件就简单的多了！ 只要将该目录移除即可视为该软件已经被移除罗！以上面为例，我想要移除 apache 只要下达『rm -rf /usr/local/apache』 就算移除这个软件啦！当然罗，实际安装的时候还是得视该软件的 Makefile 里头的 install 资讯才能知道到底他的安装情况为何的。因为例如 sendmail 的安装就很麻烦......

　　这个方式虽然有利於软件的移除，但不晓得你有没有发现，我们在运行某些命令的时候，与该命令是否在 PATH 这个环境变量所记录的路径有关，以上面为例，我的 /usr/local/apache/bin 肯定是不在 PATH 里面的，所以运行 apache 的命令就得要利用绝对路径了，否则就得将这个 /usr/local/apache/bin 加入 PATH 里面。另外，那个 /usr/local/apache/man 也需要加入 man page 搜寻的路径当中啊！

　　除此之外， Tarball 在升级的时候也是挺困扰的，怎么说呢？我们还是以 apache 来说明好了。WWW 服务器为了考虑互动性，所以通常会将 PHP+MySQL+Apache 一起安装起来。假设今天我只要升级 PHP 呢？有的时候因为只有涉及动态函式库的升级，那么我只要升级 PHP 即可！其他的部分或许影响不大。但是如果今天 PHP 需要重新编译的模块比较多，那么可能会连带的，连 Apache 这个程序也需要重新编译过才行！真是有点给他头痛的！没办法啦！使用 tarball 确实有他的优点啦，但是在这方面，确实也有他一定的伤脑筋程度。

　　最后，Tarball软件在安装时无法做软件相关性检查，从而可能使安装后的软件无法正常使用。

　　由於 Tarball 在升级与安装上面具有这些特色，亦即 Tarball 在反安装上面具有比较高的难度 (如果你没有好好规划的话～)，所以，为了方便 Tarball 的管理，通常鸟哥会这样建议使用者：

1. 最好将 tarball 的原始数据解压缩到 /usr/local/src 当中；
2. 安装时，最好安装到 /usr/local 这个默认路径下；考虑未来的反安装步骤，最好可以将每个软件单独的安装在 /usr/local 底下；
3. 为安装到单独目录的软件之 man page 加入 man path 搜寻：如果你安装的软件放置到 /usr/local/software/ ，那么 man page 搜寻的配置中，可能就得要在 /etc/man.config 内的 40~50 行左右处，写入如下的一行："MANPATH /usr/local/software/man".这样才可以使用 man 来查询该软件的线上文件罗！当然还有还要把/usr/local/software/bin目录加入到命令的搜索路径中去

　　注意：使用tarball方式安装的软件是无法通过rpm来管理的，如rpm -q software_name是查询不出你已经用tarball安装过的文件的。

　　2. rpm与dpkg

　　由於自由软件的蓬勃发展，加上大型 Unix-Like 主机的强大效能，让很多软件开发者将他们的软件使用 Tarball 来释出。 后来 Linux 发展起来后，由一些企业或社群将这些软件收集起来制作成为 distributions 以发布这好用的 Linux 操作系统。但后来发现到，这些 distribution 的软件管理实在伤脑筋， 如果软件有漏洞时，又该如何修补呢？使用 tarball 的方式来管理吗？又常常不晓得到底我们安装过了哪些程序？ 因此，一些社群与企业就开始思考 Linux 的软件管理方式。

　　于是，Linux 开发商先在固定的硬件平台与操作系统平台上面将需要安装或升级的软件编译好， 然后将这个软件的所有相关文件打包成为一个特殊格式的文件，在这个软件文件内还包含了预先侦测系统与相依软件的脚本， 并提供记载该软件提供的所有文件资讯等。最终将这个软件文件释出。用户端取得这个文件后，只要透过特定的命令来安装， 那么该软件文件就会依照内部的脚本来侦测相依的前驱软件是否存在，若安装的环境符合需求，那就会开始安装， 安装完成后还会将该软件的资讯写入软件管理机制中，以达成未来可以进行升级、移除等动作呢。

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

• dpkg：
  这个机制最早是由 Debian Linux 社群所开发出来的，透过 dpkg 的机制， Debian 提供的软件就能够简单的安装起来，同时还能提供安装后的软件资讯，实在非常不错。 只要是衍生於 Debian 的其他 Linux distributions 大多使用 dpkg 这个机制来管理软件的， 包括 B2D, Ubuntu 等等。
  
  
• RPM：
  这个机制最早是由 Red Hat 这家公司开发出来的，后来实在很好用，因此很多 distributions 就使用这个机制来作为软件安装的管理方式。包括 Fedora, CentOS, SuSE 等等知名的开发商都是用这咚咚。

　　如前所述，不论 dpkg/rpm 这些机制或多或少都会有软件属性相依的问题，那该如何解决呢？ 其实前面不是谈到过每个软件文件都有提供相依属性的检查吗？那么如果我们将相依属性的数据做成列表， 等到实际软件安装时，若发生有相依属性的软件状况时，例如安装 A 需要先安装 B 与 C ，而安装 B 则需要安装 D 与 E 时，那么当你要安装 A ，透过相依属性列表，管理机制自动去取得 B, C, D, E 来同时安装， 不就解决了属性相依的问题吗？

　　没错！目前新的 Linux 开发商都有提供这样的『线上升级』机制，透过这个机制， 原版光盘就只有第一次安装时需要用到而已，其他时候只要有网络，你就能够取得原本开发商所提供的任何软件了呢！ 在 dpkg 管理机制上就开发出 APT 的线上升级机制，RPM 则依开发商的不同，有 Red Hat 系统的 yum ， SuSE 系统的 Yast Online Update (YOU)， Mandriva 的 urpmi 软件等。

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

　　我们这里以CentOS 系统为例，使用的软件管理机制为 RPM 机制，而用来作为线上升级的方式则为 yum ！底下就让我们来谈谈 RPM 与 YUM 的相关说明吧！

　　2.1 什么是 RPM 与 SRPM

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

　　由於 RPM 文件是已经包装好的数据，也就是说， 里面的数据已经都『编译完成』了！所以，该软件文件几乎只能安装在原本默认的硬件与操作系统版本中。 也就是说，你的主机系统环境必须要与当初创建这个软件文件的主机环境相同才行！ 举例来说，rp-pppoe 这个 ADSL 拨接软件，他必须要在 ppp 这个软件存在的环境下才能进行安装！如果你的主机并没有 ppp 这个软件，那么很抱歉，除非你先安装 ppp 否则 rp-pppoe 就是不让你安装的 (当然你可以强制安装，但是通常都会有点问题发生就是了！)。所以，通常不同的 distribution 所释出的 RPM 文件，并不能用在其他的 distributions 上。举例来说，Red Hat 释出的 RPM 文件，通常无法直接在 SuSE 上面进行安装的。更有甚者，相同 distribution 的不同版本之间也无法互通，例如 CentOS 4.x 的 RPM 文件就无法直接套用在 CentOS 5.x ！因此，这样可以发现这些软件管理机制的问题是：

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

　　那怎么办？如果我真的想要安装其他 distributions 提供的好用的 RPM 软件文件时？ 呵呵！还好，还有 SRPM 这个东西！SRPM 是什么呢？顾名思义，他是 Source RPM 的意思，也就是这个 RPM 文件里面含有原始码哩！特别注意的是，这个 SRPM 所提供的软件内容『并没有经过编译』， 他提供的是原始码喔！

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

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

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

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

Tips: 为何说 CentOS 是『社群维护的企业版』呢？ Red Hat 公司的 RHEL 释出后，连带会将 SRPM 释出。 社群的朋友就将这些 SRPM 收集起来并重新编译成为所需要的软件，再重复释出成为 CentOS，所以才能号称与 Red Hat 的 RHEL 企业版同步啊！真要感谢 SRPM 哩！如果你想要理解 CentOS 是如何编译一支程序的， 也能够透过学习 SRPM 内含的编译参数，来学习的啊！

 

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

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

　　2.2 RPM 属性相依的克服方式： YUM 线上升级

　　为了重复利用既有的软件功能，因此很多软件都会以函式库的方式释出部分功能，以方便其他软件的呼叫应用， 例如 PAM 模块的验证功能。此外，为了节省使用者的数据量，目前的 distributions 在释出软件时， 都会将软件的内容分为一般使用与开发使用 (development) 两大类。所以你才会常常看到有类似 pam-x.x.rpm 与 pam-devel-x.x.rpm 之类的档名啊！而默认情况下，大部分的 software-devel-x.x.rpm 都不会安装，因为终端用户大部分不会去开发软件嘛！

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

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

图 1.5.1、YUM 使用的流程示意图

　　当用户端有升级、安装的需求时， yum 会向容器要求清单的升级，等到清单升级到本机的 /var/cache/yum 里面后， 等一下升级时就会用这个本机清单与本机的 RPM 数据库进行比较，这样就知道该下载什么软件。接下来 yum 会跑到容器服务器 (yum server) 下载所需要的软件，然后再透过 RPM 的机制开始安装软件啦！这就是整个流程！

　　3.管理的抉择：RPM 还是 Tarball

　　这一直是个有趣的问题：『如果我要升级的话，或者是全新安装一个新的软件， 那么该选择 RPM 还是 Tarball 来安装呢？』，事实上考虑的因素很多，不过鸟哥通常是这样建议的：

1. 优先选择原厂的 RPM 功能：
   由於原厂释出的软件通常具有一段时间的维护期，举例来说， RHEL 与 CentOS 每一个版本至少提供五年以上的升级期限。这对於我们的系统安全性来说，实在是非常好的选项！ 何解？既然 yum 可以自动升级，加上原厂会持续维护软件升级，那么我们的系统就能够自己保持在软件最新的状态， 对於资安来说当然会比较好一些的！ 此外，由於 RPM 与 yum 具有容易安装/移除/升级等特点，且还提供查询与验证的功能，安装时更有数码签章的保护， 让你的软件管理变的更轻松自在！因此，当然首选就是利用 RPM 来处理啦！
   
   
2. 选择软件官网释出的 RPM 或者是提供的容器网址：
   不过，原厂并不会包山包海，因此某些特殊软件你的原版厂商并不会提供的！举例来说 CentOS 就没有提供 NTFS 的相关模块。此时你可以自行到官网去查阅，看看有没有提供相对到你的系统的 RPM 文件， 如果有提供容器网址，那就更好啦！可以修改 yum 配置档来加入该容器，就能够自动安装与升级该软件！ 你说方不方便啊！
   
   
3. 利用 Tarball 安装特殊软件：
   某些特殊用途的软件并不会特别帮你制作 RPM 文件的，此时建议你也不要妄想自行制作 SRPM 来转成 RPM 啦！ 因为你只有区区一部主机而已，若是你要管理相同的 100 部主机，那么将原始码转制作成 RPM 就有价值！ 单机版的特殊软件，例如学术网络常会用到的 MPICH/PVM 等平行运算函式库，这种软件建议使用 tarball 来安装即可， 不需要特别去搜寻 RPM 罗！
   
   
4. 用 Tarball 测试新版软件：
   某些时刻你可能需要使用到新版的某个软件，但是原版厂商仅提供旧版软件，举例来说，我们的 CentOS 主要是定位於企业版，因此很多软件的要求是『稳』而不是『新』，但你就是需要新软件啊！ 然后又担心新软件装好后产生问题，回不到旧软件，那就惨了！此时你可以用 tarball 安装新软件到 /usr/local 底下， 那么该软件就能够同时安装两个版本在系统上面了！而且大多数软件安装数种版本时还不会互相干扰的！ 嘿嘿！用来作为测试新软件是很不错的呦！只是你就得要知道你使用的命令是新版软件还是旧版软件了！

　　所以说，RPM 与 Tarball 各有其优缺点，不过，如果有 RPM 的话，那么优先权还是在於 RPM 安装上面，毕竟管理上比较便利，但是如果软件的架构差异性太大， 或者是无法解决相依属性的问题，那么与其花大把的时间与精力在解决属性相依的问题上，还不如直接以 tarball 来安装，轻松又惬意！

转载于:https://www.cnblogs.com/beanmoon/archive/2012/10/30/2746103.html