Ubuntu软件包管理

 Ubuntu Linux采用了Debian的软件包管理机制。由于软件包具有易用性、灵活性和扩展性的特点，再加上Internet的支持，使用户随时都能拥有最新的Ubuntu系统，这也是Ubuntu受到推崇的一个重要原因。因而，Deb软件包管理也成为Ubuntu中最有活力的部分。本章介绍Ubuntu软件包管理和dpkg软件包管理器。

 

1

8.1 Deb软件包概述

Deb软件包本质上是文件包，这点类似于tar文件将多个文件合并为一个归档文件。但是Deb的身价不在于整合文件，而在于使应用程序更易于传播。
8.1.1  流行的两种软件包管理机制

最初，基于Linux系统的开发者在完成应用程序开发后，将很多二进制文件发给用户，用户使用之前需要将相关程序逐个安装。因此，Debian Linux首先提出“软件包”的管理机制——Deb软件包，将应用程序的二进制文件、配置文档、man/info帮助页面等文件合并打包在一个文件中，用户使用软件包管理器直接操作软件包，完成获取、安装、卸载、查询等操作。

随即，Redhat Linux基于这个理念推出了自己的软件包管理机制——Rpm软件包。当然，Redhat Linux采用了自己的打包格式生成Rpm包文件，由Rpm包管理器负责安装、维护、查询，甚至软件包版本管理。由于Redhat Linux系统的普及，Rpm软件包被广泛使用，甚至出现第三方开发的软件管理工具，专门管理Rpm格式的软件包。

随着Linux操作系统规模的不断扩大，系统中软件包之间复杂的依赖关系，导致Linux用户麻烦不断。为了解决这个问题，Debian Linux开发出了APT软件包管理器。它能够自动检查和修复软件包之间的依赖关系。并且，利用Internet网络带来的快捷的连通手段，APT工具可以帮助用户主动获取软件包。因此，APT工具再次促进了Deb软件包更为广泛地使用，成为Debian Linux的一个无法替代的亮点。

Ubuntu Linux系统的软件包管理机制延续了Debian的包管理方法。
8.1.2  软件包的类型

Debian包文件包含了二进制可执行文件、库文件、配置文件和man/info帮助页面等文档。通常Debian包文件的后缀为.deb，因此称为“Deb软件包”。Ubuntu有两种类型的软件包：二进制软件包（deb）和源码包（deb-src）。

  ●    二进制软件包（Binary Packages）：包含可执行文件、库文件、配置文件、man/info页面、版权声明和其他文档。

  ●    源码包（Source Packages）：包含软件源代码、版本修改说明、构建指令以及编译工具等。先由tar工具归档为.tar.gz文件，然后再打包成.dsc文件。

用户不确定一个软件包具体类型时，可以使用file命令查看文件类型。例如下面命令用于证实一个软件包的文件类型是否是Deb软件包文件。

wdl@UbuntuFisher:~$ file  g++_4.1.2-9ubuntu2_i386.deb

g++_4.1.2-9ubuntu2_i386: Debian binary package (format 2.0)

在Ubuntu Linux中，需要说明一个概念——虚拟软件包。将系统中具有相同或相近功能的多个软件包作为一个软件包集合，称为虚拟软件包，并指定其中一个软件包作为虚拟软件包的默认首选项。提出虚拟软件的意图就是为了防止软件安装过程中发生冲突。例如，exim、sendmail和postfix软件包都是用于邮件传输代理，将“mail-transport-agent”指定为它们的虚拟软件包。当用户安装“mail-transport-agent”时，将选择安装exim、sendmail和postfix其中的首选项。
8.1.3  软件包的命名

在Ubuntu Linux中，软件包的命名遵循以下约定：

Filename_Version-Reversion_Architecture.deb

其中，Filename表示软件包文件名，Version表示软件版本号，Reversion表示修订版本号，Architecture表示适用计算机架构。通常，修订版本号是由Ubuntu开发者或创建这个软件包的人指定。在软件包被修改过之后，将修改版本号加1。

以g++_4.1.2-9ubuntu2_i386.deb软件包为例，g++是软件包名，4.1.2是软件版本号，9ubuntu2是修订版本号，i386是适用的计算机架构。
8.1.4  软件包的优先级

Ubuntu Linux为每个软件包指定了一个优先级，作为软件包管理器选择安装和卸载的一个依据。表8.1列出了Ubuntu定义的所有软件包优先级描述。

表8.1                                                         软件包优先级描述
级    别 
含    义 
补 充 说 明

Required（必须） 
高

 

低 
该级别软件包是保证系统正常运行所必须的 
包含所有必要的系统工具。尽管Require级别的软件不能满足整个系统的服务，但至少能够保证系统正常启动。如果删除其中一个软件包，系统将受到损坏而无法恢复。例如bash、mount、upstart

Important（重要） 
若缺少该级别软件包，系统会运行困难或不好操作 
该级别软件包是一些实现系统底层功能的程序。例如，aptitude、ubuntu-keyring、cpio

Standard（基本） 
该级别软件包是任何Linux系统的标准件 
该级别的软件包可以支撑命令行控制台系统运行，通常作为默认安装选项，例如，memtest86、telnet、pppconfig、ed

Optional（可选） 
该级别软件包是否安装不影响系统的正常运行 
该级别的软件包用于满足用户特定的需求或服务，它们不会影响系统的正常运行。例如，X11、mysql、openoffic.org

Extra（额外） 
该级别软件包可能与其他高级别软件包存在冲突 

在Ubuntu系统中规定，任何高优先级的软件包都不能依赖于低优先级的软件包。这样可以实现按照优先级一层层冻结系统。在新版本发布准备阶段，优先级的作用就显得更为重要。

基本系统由Required级和Important级软件包组成，属于这类优先级的软件包首先被冻结。由于这些软件包是其他软件包所依赖的，它们能保证整个系统的稳定，这是Ubuntu发布新版本所必需的。然后，冻结Standard级软件包，紧接着，在发布新版本之前对Optional级和Extra级软件包进行冻结。
8.1.5  软件包的状态

在使用系统过程中，用户会不断的安装、卸载软件包。为了记录用户的安装行为，Ubuntu对软件包定义了以下两种状态，如表8.2所示。

  ●    期望状态：标记用户希望将某个软件包处于的状态。

  ●    当前状态：标记用户操作该软件包后的最终状态。

表8.2                                                           软件包状态定义
类    别 
状    态 
状  态  符 
描    述

期望状态 
未知（unknown） 
u 
用户并没描述他想对软件包进行什么操作

已安装（install） 
i 
该软件包已安装或升级

删除（remove） 
r 
软件包已删除，但不想删除任何配置文件

清除（purge） 
p 
用户希望完全删除软件包，包括配置文件

保持（hold） 
h 
用户希望软件包保持现状，例如，用户希望保持当前的版本，当前的状态

当前状态 
未安装（Not） 
n 
该软件包描述信息已知，但仍未在系统中安装

已安装（installed） 
i 
已完全安装和配置了该软件包

仅存配置(config-file) 
c 
软件包已删除，但配置文件仍保留在系统中

仅解压缩（Unpacked） 
U 
已将软件包中的所有文件释放，但尚未执行安装和配置

配置失败（Failed-config） 
F 
曾尝试安装该软件包，但由于错误没有完成安装

不完全安装（Half-installed） 
H 
已开始进行提取后的配置工作，但由于错误没有完成安装

8.1.6  软件包的依赖性关系

Linux操作系统是一个复杂系统。这个系统包含了大量的软件组件。但是，若要求它们能够成为一个有机整体，支撑Linux系统的正常运转，就必须要求各个组件密切配合。这就是Linux操作系统最初的设计理念——尽可能提高软件系统内部的耦合度。换句话说，某个软件组件是否能够正常运行或运行的更好，依赖于其他一些软件组件的存在。这样做的好处是，使系统更加致密、紧凑，减少中间环节可能引发的错误。然而，随即带来的两个负面问题是，软件组件依赖和软件组件冲突问题。

为了解决这个问题，Debian提出了程序依赖性机制，并做详细的定义。程序依赖性是用来描述独立运行程序与当前系统中程序之间存在的关联程度。表8.3列出了Ubuntu中依赖性关系的定义。

表8.3                                                           依赖性关系定义
依 赖 关 系 
关 系 描 述

依赖（depends） 
要运行软件包A必须安装软件包B，甚至还依赖于B的特定版本，通常版本依赖有最低版本限制

推荐（recommends） 
软件包维护者认为所有用户都不会喜欢缺少软件包A的某些功能，而这些功能需要B来提供

建议（suggests） 
软件包B能够增强软件包A的功能

替换（replaces） 
软件包B安装的文件被软件包A中的文件删除或覆盖了

冲突（conflicts） 
如果系统中安装了软件包B，那么软件包A将无法运行。“Conflicts”常和“Replaces”同时出现

提供（provides） 
软件包A中包含了软件包B中的所有文件和功能

软件包管理器将依据软件包“依赖关系”完成组件的安装或卸载。例如，包含GNU C编译器（gcc）的软件包依赖于包含链接器和汇编器的binutils软件包。如果用户试图在没有安装binutils的情况下安装gcc，软件包管理器将会中止安装，并出现错误提示，要求用户事先安装binutils。

 

还有更多关于软件包管理工具的使用可详见

[转自]http://book.csdn.net/bookfiles/710/10071022115.shtml