• 如果能够将软件预先在相同的硬件与操作系统上编译好才发布的话,不就能够让相同的 Linux发行版有完全一致的软件版本吗?
• 如果再加上简易的安装、删除、管理等功能的话,软件管理就会简易得多。
• 有这种东西吗?
• RPM与YUM

22.1软件管理器简介

• 前一章提到以源码方式安装软件,也就是用厂商发布的Tarball来安装
• 每次安装软件都要检测
  • 操作系统环境、设置编译参数、实际的编译,
  • 最后还要安装软件到特定位置

 

• 如果我的Linux系统与厂商的系统一模一样,那么厂商的系统上面编译出来的执行文件,自然也就可在我的系统上运行
• 厂商先在它们的系统上面编译好用户所需软件
  • 然后将这个编译好的可执行的软件直接发布给用户来安装,
  • 由于我们本来就使用厂商的Linux发行版
  • 所以系统(硬件与操作系统)是一样的
  • 那么使用厂商提供的编译过的可执行文件就没有问题

 

• 如果在安装时候还可以加上ー些与这些程序相关的信息,将它建立成为数据库,不就可安装、反安装、升级与验证
• Linux上至少就有两种这方面的软件管理器,RPM与 Debian的dpkg
• Centos以RPM为主,但也不能不知道dpkg

22.1.1 Linux界的两大主流:RPM与DPKG

• *软件的蓬勃发展,加上大型UNX-ike主机的强大性能,很多软件开发者将他们的软件用Tarball发布
• Linux发展起来后,一些企业或社区将这些软件收集起来制作成为 Linux.发行版以便大家使用。
• 但后来发现到,这些 Linux发行版的软件管理实在伤脑筋,软件有漏洞时,又该如何修补?
• 用Tarball A的方式来管理吗?又常常不晓得到底我们安装过了哪些程序?因此,一些社区与企业就开始思考 Linux的软件管理方式。

 

• Linux开发商先在固定的硬件平合与操作系统平合上面将需要安装或升级的软件编译好,然后将这个软件的所有相关文件打包成为一个特殊格式的文件,在这个软件安装文件内还包含了预先检测系统与依赖软件的脚本,并提供记录该软件提供的所有文件信息等,最终将这个
  软件安装文件发布。
• 客户端获取这个文件后,只需通过特定的命令来安装,那么该文件就会依照内部的脚本来检测依赖的辅助软件是否存在,若安装的环境符合需求,那就会开始安装,安装完成后还会将该软件的信息写入软件管理机制中,以便未来可进行升级、删除

 

• 目前Linux界软件安装方式最常见的有两种
• dpkg
• 最早是由 Debian Linux社区所开发,通过dpkg的机制, Debian提供的软件就能够简单地进行安装,同时还能提供安装后的软件信息,非常不错。只要是衍生于 Debian的 Linux发行版大多使用dpkg这个机制来管理软件,包括B2D、 Ubuntu等。

 

• RPM
• 最早由Red Hat开发,后来实在很好用,因此很多发行版就使用这个机制来作为软件安装的管理方式。
• 包括 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)等。

 

• 用的是Centos系统。
• 所以:使用的软件管理机制为RPMM,
  • 而用来作为在线升级的方式则为YUM。
• 下面看看RPM与YUM的相关说明。

22.1.2 RPM与SRPM

• Redhat Package Manager
• RPM是以一种数据库记录的方式来将你要的软件安装到你的Linux系统
  • 的一套软件管理机制。

 

• 你要安装的软件先编译过

  • 打包成为RPM机制的文件
  • 通过打包好的软件里面默认的数据库
  • 记录这个软件要安装的时候必须具备的依赖属性软件

• 安装时,RPM会先依照软件里面的数据查询Linux主机的依赖属性软件是否满足,满足安装,不满足则不安装

• 安装时就将该软件的信息整个写入RPM的数据库,以便未来查询、验证与反安装。

• 1.由于已经编译完成并且打包完毕,所以软件传输与安装上很方便

• 2.软件信息都记录在Linux主机的数据库上,方便查询、升级与反安装,但这RPM文件是已经打包好的数据,里面的数据已经都
  【编译完成了,所以,该软件安装文件几乎只能安装在原本默认的硬件与操作系统版本中。你的主机系统环境必须要与当初建立这个软件安装文件的主机环境相同才行。

• rp- pppoe这个ADSL拨号软件,必须要在ppp这个软件存在的环境下才能安装

• 如果你的主机没有ppp这个软件,那么抱歉,除非你先安装ppp

• 否则rp-ppoe就是不让你安装的(当然你可以强制安装,但是通常都会有点问题发生)。

 

• 不同Linux发行版所发布的RPM文件,不能用在其他的Linux发行版上。
• Red Hat发布的RPM文件,通常无法直接在SUSE上面安装。
• 相同Linux发行版的不同版本之间也无法互通,
  • Centos6.x的RPM文件就无法直接用在 Centos7.x。
    1.软件安装的环境必须与打包时的环境需求一致或相当
    2.需要满足软件的依赖属性需求
    3.反安装时要特别小心,最底层的软件不可先删除,否则可能造成整个系统的问题

 

• 如果要安装其他 Linux发行版提供的RPM软件包时?
• 还有SRPM。
• Source RPM,
• 也就是这个RPM文件里面含源代码
• SRPM所提供的软件内容【并没有经过编译),它提供的是源代码。

 

• SRPM的扩展名是***.src.rpm
• SRPM提供的是源代码,那么为什么不用 Tarball直接来安装?
• SRPM虽然是源代码,但仍有该软件所需要的依赖性软件及所有RPM文件所提供的数据
• 与RPM不同,它也提供参数配置文件(就是configure与makefile)。
• 所以,如果下载SRPM,那么安装该软件时,必须要先将该软件以RPM管理的方式编译,此时SRPM会被编译成为RPM文件然后将编译完成的RPM文件安装到 Linux系统

 

• 通常一个软件在发布的时候,都会同时发布该软件的RPM与SRPM。
• RPM文件必须要在相同的Lnux环境下才能够安装,而SRPM既然是源代码的格式,自然就可修改SRPM内的参数配置文件,然后重新编译产生能适合我们 Linux的RPM文件,就可以将该软件安装到我们的系统中,而不必与原作者打包的 Linux环境相同

 

22.1.3 i386、i586、i686、 noarch、X86_64

 

 

• 每一次更新版本就需要有一个版本的信息,又分主版本跟次版本。
• 主版本为3,在主版本的架构下修改部分源代码内容,而发布一个新的版本,就是次版本。就是11,所以版本名就为3.11
• 发布版本次数
• 通常就是编译的次数。
  • 那么为何要重复编译?
  • 同一版的软件中,由于有某些bug或安全上的顾虑,
  • 必须要进行小幅度patch或重设一些编译参数,
  • 设置完成后重新编译并打包成RPM文件,
  • 就有不同的打包数出现
• 操作硬件平台
• RPM可以适用在不同的操作平合上,
  • 不同的平台设置的参数还是有所差异性。
  • 高级的CPU来优化参数的设置,
  • 这样才能够用高级CPU所带来的硬件加速,
  • i386、i586、i686、X86_64、 noarch等版本的文件出现

 

 

• 2015年为止,就算是旧的个人计算机,堪用与能用的设备大概都至少是 Intel Core2以上等级的计算机,大多数都是64位系统。
• 因此目前entos7仅推出x86_64的软件版本,并没有提供i686以下级别的软件。
• 如果你的系统还是很老旧的机器,那才有可能不支持64位的 Linux系统。
• 目前仅存的软件版本大概也只剩下i686及x8664还有不分版本的 noarch而已i386只有在某些很特别的软件上才看到。

 

受惠于目前X86系统的支持方面,新的CPU都能够执行旧型CPU所支持的软件,也就是说硬件方面都可以向下兼容的,因此最低级别的i386软件可以安装在所有的x86硬件平台上面,不论是32位还是64位,

• 目前硬件大多是64位的,因此你可以在该硬件上面
  安装x8664或386级别的RPM软件。但在你的旧型主机,例如 Pentium I/ Pentium432位机器上面,就不能够安装x8664的软件。

 

• 只要选择i686版本来安装在你的x86硬件上面就肯定没问题。
• 但如果强调性能的话,还是选择搭配你硬件的RPM文件吧!毕竟该软件才有针对你的CPU硬件平台进行过参数优化的编译嘛。