5.4. 通过dpkg来操作软件包
dpkg
是系统层面处理 Debian 软件包的基础指令。若您有 .deb
软件包,可以用 dpkg
安装及分析其内容。但此指令只能看到 Debian 世界的部分内容:它知道系统安装那些软件包、指令列给了那些参数,但不知道还有那些可用的软件包。因此,没有相依性就完了。apt
之类的工具,则可产生相依性清单,尽量自动安装软件包。
说明 dpkg
或 apt
?
dpkg
应视为系统工具 (背景) 之一,而 apt
则是较倾向用户的工具,可克服前者的限制。这些工具各有其限制,共同解决特定的作业。
5.4.1. 安装软件包
首先,dpkg
是安装 Debian 已经可用软件包的工具 (因为不需下载任何东西)。我们使用它的 -i
或 --install
选项。
例 5.2. 通过dpkg
来安装一个软件包
#
通过dpkg
我们可以看到安装时的不同步骤;因此我们会知道在什么时候可能会发生错误。安装也被分为两个阶段:首先解压包,然后配置它。apt-get
会利用这一点,然后有限的调用dpkg
(因为每次调用都要把数据加载到内存中,特别是那些在名单中已经被安装的文件)。
例 5.3. 分开解压和配置
#
有时dpkg
在安装软件包的时候会失败并且返回一个错误;如果用户命令dpkg忽略掉这个错误,那么它仅仅会提示一个警告;这也就是我们有一个不同的--force--*
选项。dpkg --force-help
,或者是dpkg的帮助文档,有一个这些选项的详细清单。最常见的错误是,你迟到会遇到这样一个文件冲突,当一个软件包包含的文件中已经安装了另外一个软件包。:
Unpacking libgdm (from .../libgdm_3.8.3-2_amd64.deb) ...
dpkg: 处理 /var/cache/apt/archives/libgdm_3.8.3-2_amd64.deb (--unpack) 时发生错误:
试图覆写 '/usr/bin/gdmflexiserver',也同时在软件包 gdm3 3.4.1-9 内
在这种情况下,如果你认为文件替换该文件可能不会对系统的稳定性造成重大的风险(通常情况下),你可以使用--force-overwrite
选项来告诉dpkg
去忽略这个错误并且覆盖该文件。
当然这里有非常多的--force-*
选项,只是--force-overwrite
使用的非常频繁。这些选项仅存在特殊的情况下,所以最好是不去使用它们以便遵守软件包的管理机制。不要忘了,这些管理规则可以确保你的系统的稳定性和一致性。
注意 使用--force-*
的影响
若不小心使用 --force-*
的选项,可能造成 APT 命令家族拒绝运作的困境。在相依性不足或冲突的情况下,使用部分选项后,仍可安装该等软件包。结果就是相依性不足的不一致系统,APT 命令将拒绝运行任何工作,直到系统恢复一致 (通常包括安装遗失的相依软件包或移除问题软件包)。通常出现以下的消息,安装新版 rdesktop 时忽略其对新版 libc6 的相依性:
#
确信其分析结果的勇敢管理者,可能选择忽略使用 --force-*
选项时发生的相依性问题与冲突。结果是,想要继续使用 apt
或 aptitude
的话,他们必须先编辑 /var/lib/dpkg/status
以删除/修改相依性问题或冲突。
这是一种丑陋的黑客行为,除了极为必要的情况,否则不该发生。比较常见的手法是,重新编译有问题的软件包 (见 第 15.1 节 “从源码重建安装包”) 或从 stable-backports
里 (see 第 6.1.2.4 节 “向后移植到稳定版(Stable Backports)”),使用新版本 (可能已修复该问题) 的软件包。
5.4.2. 软件包移除
使用 dpkg
加上 -r
或 --remove
选项,再加上软件包名称,就可移除该软件包。然而,这种方式的移除并不完整:仍保留所有的配置文件、维护脚本、记录文件 (系统记录档) 及该软件包的其他用户数据。这种方式是停用程序,仍可以相同的配置快速地再安装回来。完全移除该软件包的所有相关文件,应使用 -P
或 --purge
选项,再加上软件包名称。
例 5.4. 移除与清除 debian-cd 软件包
#
5.4.3. 查询 dpkg 的数据库,并检查 .deb 文件
回到基础 选项的语法
“长” 版 (一个或多个字,前置两个链接号) 与 “短” 版 (一个字母,通常是长版字的第一个字母,前置一个链接号) 软件包都有该等选项。这是 POSIX 标准常见的用法。
做结论前,我们将学习查找内部数据库以获取信息的 dpkg
选项。先给长版的选项再给对应的短版选项 (其参数是一样的) 以 --listfiles *软件包*
(或 -L
) 为例,列出该软件包安装的文件清单;--search *文件*
(或 -S
),寻找包括该文件的套性;--status *软件包*
(或 -s
),显示该软件包的标头;--list
(或 -l
),显示该系统内软件包清单与安装状态;--contents *file.deb*
(或 -c
),列出 Debian 指定软件包清单;--info *file.deb*
(或 -I
),列出该软件包的标头。
例 5.5. dpkg
的各种查询
$
更进一步 版本的对比
因为 dpkg
是处理 Debian 软件包的程序,它也能够逻辑地比较版本编号。所以有 --compare-versions
选项,以外部程序使用它 (尤其是被 dpkg
本身运行的配置脚本)。这个选项需要三个参数:版本编号、比较操作数、以及第二个版本编号。可能的操作数为 lt
(小于)、le
(大于或等于)、eq
(等于)、ne
(不等于)、ge
(大于或等于)、以及 gt
(大于)。若比较结果正确,dpkg
送回 0 (成功);若不正确,则送回 0 以外的数值 (表示失败)。
$
注意前例最后一个比较的失败:dpkg
、pre
,表示为预发布版,没有特别的意义,此程序以比较数字版本 (a < b < c …) 相同的方式比较字顺版本。所以,“0pre3
” 大于 “0
”。我们以毛毛虫 “~
” 表示该软件包的预发布版:
$
5.4.4. dpkg的日志文件
dpkg
把所有的交易记录存在名为 /var/log/dpkg.log
的日志档。这个日志档的内容颇为详尽且啰唆,记录软件包被 dpkg
处理的每个进程。追踪 dpkg 的每个作为之外,日志档还保留系统发展的记录:可以覆查每个软件包的安装与移除步骤,对于了解最近的变动极有帮助。此外,还记录所有的版本,可以交互检查 changelog.Debian.gz
的内容,查看有问题的软件包或在线的错误报告。
5.4.5. 多架构支持
所有的 Debian 包在它们的管控信息中都有一个架构
字段。该字段可包含:“全部
“(对与架构无关的包),或者它的目标架构名称(如“amd64”, “armhf”,…)。对于后者,默认情况下,dpkg
将只能接受安装与主机架构匹配的软件包,主机架构可通过dpkg --print-architecture
来获得。
该限制确保用户不会因为错误架构编译的二进制文件而挂掉。一切都很完美,除了(某些)计算机可以运行多架构的二进制文件,或者以本地方式(“amd64“系统可运行”i386“二进制文件)运行,或者以模拟器运行。
5.4.5.1. 启用多架构
dpkg
的多架构支持允许用户定义可安装于当前系统的“异质架构” 。这可以方便的通过 dpkg --add-architecture
完成,如下例。有一相应的 dpkg --remove-architecture
以放弃对异质架构的支持,但仅可用于未余留该架构软件包的情况。
#
备注 APT 的多架构支持
当 dpkg 已配置为支持异质架构时,APT将会自动检测,并在更新过程中开始下载相应的软件包
文件。
异质软件包可通过 apt install *软件包*: *架构*
安装。
实例 在 amd64 架构上使用专有 i386 二进制文件
对于多架构,有多种使用案例,但最常见的是在 64 位系统(amd64)上执行 32 位二进制文件(i386)的可能性,特别是因为一些流行的专有应用(如 Skype)仅提供 32 位版本。
5.4.5.2. 多架构相关的变更
要让多架构真正实用和可用,库文件需要重新打包,并移动到一个用于特定架构的文件夹以便可以并存安装多重副本(针对不同架构)。这样的更新包中包含“Multi-Arch: same
“头字段,以告诉打包系统此软件包的不同架构可以安全地并存安装(而且这些包仅能满足同架构软件包的依赖)。由于多架构在 Debian Wheezy 中为初次引入,因而尚未完成所有库文件的转换。
$
值得注意的是,Multi-Arch: same
软件包需具备能够明晰识别架构的名称。它们也能够与相同包的其他实例共享文件;dpkg
确保所有的包在共享时具有逐位对应识别的文件。最后但并非最不重要的,一个包的所有实例必须为相同版本。它们必须同时升级。
多架构支持也带来了在依赖处理方式上的一些有趣的挑战。要满足依赖,需要:或者有Multi-Arch: foreign
标识的软件包,或者架构上能匹配已声明依赖的软件包(在该依赖方案处理中,架构无关包假定为同样架构,而非主机架构)。通过 *软件包* :any
语法,依赖可以被弱化,以便允许任意架构能够满足依赖,但异质软件包仅能满足如下依赖:有“ Multi-Arch: allowed
”标识的依赖。