Linux 包管理器

引言

软件包管理系统或软件包管理器是一组软件工具。它以高效的方式自动完成计算机操作系统上计算机程序的安装、升级、配置和删除过程。软件包管理器与软件包、存档文件中的数据和软件分发一起工作。

软件包包括元数据，例如软件的名称、其目的描述、校验和（最好是加密哈希函数）、依赖项列表、供应商和版本号，这些对于软件的正常运行至关重要。

• 元数据在安装时保存在本地软件包的数据库中。
• 通常，软件包管理器管理版本信息和软件依赖项的数据库，以防止缺少先决条件和软件不匹配。
• 它们与应用程序商店、二进制存储库管理器和软件存储库密切合作。
• 软件包管理器旨在消除手动更新和安装的需要。
• 特别是，对于操作系统通常包含数百个或更多不同软件包的大型组织来说，它可能很有帮助。

软件包管理器的功能

软件软件包可以定义为包含计算机程序和开发所需的基本元数据的存档文件。系统程序可能在必须先构建和编译的源代码中。

软件包元数据包含软件包版本、软件包描述和依赖项（需要预先安装的软件包）。许多软件包管理器都具有在用户命令下安装、卸载、维护或查找软件包的操作。

软件包管理系统包含一些典型的功能，如下所述：

• 处理文件存档器以提取软件包存档。
• 分别通过验证其数字证书和校验和来确保软件包的真实性和完整性。
• 通过应用程序商店或软件存储库更新、安装、下载或查找现有软件。
• 通过功能组合软件包，以减少用户的困惑。
• 维护依赖项，以确保软件包已与所有需要的软件包一起安装。因此，避免“依赖地狱”。

已编译软件包（本地）的前端

系统管理员可以借助软件包管理软件之外的其他工具来安装和管理软件。例如，本地管理员可能会下载（未打包的）源代码，编译它，然后安装它。

这可能导致本地系统状态与软件包管理器状态数据库不同步。本地管理员将需要采取一些额外措施，例如手动将修改集成到软件包管理器中或管理一些依赖项。

有一些工具可以确保编译后的软件包（本地）与软件包管理一起开发。

CheckInstall 适用于 .rpm 或 .deb 文件的发行版以及 Slackware Linux。对于像 Arch Linux 这样的混合系统和像 Gentoo Linux 这样的基于配方的系统，可以首先指定一个配方，然后确认软件包适合本地软件包数据库。

分布式库的挑战

许多依赖动态库链接而不是静态库链接的计算机系统将机器指令的库（可执行文件）分发到应用程序和软件包中。

在这些类型的系统中，不同软件包需要库版本之间的典型关系会导致一个称为“依赖地狱”的挑战。

在处理动态链接库时，在 Microsoft Windows 上也称为“DLL 地狱”。良好的软件包管理对于这些系统至关重要。

从 OPENSTEP 开始，框架系统就是为了解决这个问题而做的尝试，它允许同时安装多个库版本，并允许许多软件包描述它们链接到哪个版本。

配置维护

配置文件的升级在软件升级时尤其成问题。至少在 Unix 上，因为软件包管理器最初是文件存档实用程序的扩展。

通常，它们只是保留或覆盖配置文件，而不是对其使用规则。当配置文件格式修改时，可能会出现一些问题。例如，如果旧配置文件没有明确禁用必须显示的新选项。一些软件包管理器（如 Debian 的 dpkg）允许在安装时进行配置。在某些其他情况下，希望使用默认配置安装软件包，并在安装时（无头）将配置覆盖到大量系统。这种类型的安装（预配置）也由 dpkg 支持。

升级抑制

如果用户与软件包管理软件协作以进行升级，传统上会向用户提供要运行的操作列表（通常是要升级的软件包列表，并可能提供新旧版本号）。

它允许用户选择单个软件包进行升级或批量升级。各种软件包管理器可以配置为从不升级许多软件包，或仅在旧标准中检测到严重不稳定或漏洞时才升级它们，如软件包所指定。有时，此过程称为版本固定。

例如

yum 支持使用 exclude=openoffice* 语法

pacman 使用语法 Ignore=openoffice （在这两种情况下，都用于抑制升级 openoffice）

dselect 和 dpkg 通过软件包选择中的 hold 标志部分支持它。

aptitude 有 “forbid” 和 “hold” 标志。

portage 通过配置文件支持它，即 package.mask。

APT 通过复杂的 “pinning” 方法扩展了标志，即 hold（用户也可以将软件包列入黑名单）。

仓库 (Repositories)

为了让用户更好地控制允许安装到其系统上的软件类型（有时是出于分发商方面的方便和法律原因），软件有时会使用许多软件存储库进行下载。

级联软件包删除

一些更高级的软件包管理方面支持“级联软件包删除”，其中依赖于目标软件包的每个软件包以及目标软件包依赖的每个软件包也会被删除。

命令比较

然而，所有特定软件包管理器的命令都是唯一的。这些命令在很大程度上是可翻译的，因为大多数软件包管理器都提供相同的功能。

软件包管理器的普及

dpkg 等软件包管理器早在 1994 年就已推出。各种面向二进制软件包的 Linux 发行版严重依赖软件包管理系统作为其维护和管理软件的主要手段。

许多移动操作系统，如 Windows Phone、iOS（类 Unix）和 Android（基于 Linux），几乎都依赖于各自供应商的应用程序商店。因此，它们使用自己的软件包管理系统（专用）。

与安装程序的比较

通常，软件包管理器被称为“安装管理器”。这可能会导致安装程序和软件包管理器之间混淆。下面列出了一些主要区别：

与自动化实用程序的比较

几乎所有的软件配置管理系统都将部署软件和构建软件视为独立的。通常，构建自动化实用程序接收系统上已有的可读源代码文件，它加速了将它们转换为相似系统上的可执行软件包（二进制）的过程。

通常，在其他一些系统上运行的软件包管理器随后从 Internet 下载这些可执行软件包（预构建的二进制文件），然后安装它们。

尽管如此，这两种类型的工具都包含一些共同因素，如下所述：

• 软件包管理器中应用依赖图拓扑排序，以处理许多二进制组件之间的依赖关系。
• 它也应用于构建管理器中，以处理许多源组件之间的依赖关系。
• 各种 makefile 不仅提供对构建可执行文件的支持。
• 它们还支持使用 make install 安装。
• 所有软件包管理器都支持将源代码（可读）转换为二进制可执行文件，然后将其安装用于基于源代码的发行版，如 Homebrew、Sorcery、Portage 等。

一些工具，如 A-A-P 和 Maak，旨在管理部署和构建。它们也可以用作软件包管理器或构建自动化实用程序，或两者兼而有之。

基本软件包管理器及其格式

通用软件包管理器

它也称为二进制存储库管理器。此软件包管理器是一种软件工具，旨在优化软件开发过程中生成和使用的二进制文件、软件包和工件的存储和下载。

通用软件包管理器旨在标准化用户处理每种软件包类型的方式。它们为用户提供了围绕每种工件类型使用合规性和安全指标的能力。它们已被指定为处于 DevOps 工具链的中间位置。

开源和免费软件系统

通过开源和免费软件的行为，在几个操作系统上已经存在具有兼容和相似许可证的软件包。

这些软件包可以通过内部复杂且可配置的打包系统进行分发和组合，以管理几个特定版本冲突和依赖项以及软件排列。

此外，一些开源和免费软件的打包系统本身也作为开源和免费软件发布。

Windows 和 Mac OS X 等操作系统中的软件包管理与 Linux 等开源和免费软件系统中的软件包管理之间的一个区别是，开源和免费软件系统允许从类似的机制升级和安装第三方软件包。而 Windows 和 Mac OS X 的许多软件包管理器将分别升级 Microsoft 和 Apple 提供的软件。

通过将相应的存储库 URL 添加到软件包管理的配置文件中，可以不断升级第三方软件。

软件包格式

所有软件包管理器都依赖于它们可以管理的软件包的元数据和格式。软件包管理器要求文件组与特定软件包管理器一起分组，并包含适当的元数据（如依赖项）。

核心实用程序集合通常通过这些软件包管理通用安装，并且多个软件包管理器应用这些实用程序来提供附加功能。

示例

1. yum 依赖 rpm 作为后端。Yum 通过添加简单配置等功能来开发后端功能，以维护系统网络。
2. Synaptic 软件包管理器通过应用 Advanced Packaging Tool 库提供 GUI，该库依赖于 dpkg。

Alien 可以定义为在不同 Linux 软件包格式之间进行转换的程序。它支持 Slackware (.tgz, .tlz, .tbz, .txz) 软件包、Solaris (.pkg)、Stampede (.slp)、.deb、.rpm 软件包和 Linux Standard Base (LSB) 兼容之间的转换。

在几个移动操作系统中，例如 Google Play 使用 Android 应用程序软件包（简称 APK）的软件包格式，而 Windows 应用商店使用 XAP 和 APPX 的格式。Windows 应用商店和 Google Play 都包含同名的软件包管理器。

应用程序级软件包管理器

对于编程语言的操作系统和功能受限的操作系统，有一些（附加）软件包管理器，开发人员需要当前的库。应用程序级软件包管理器专注于软件系统的一小部分，而不是系统级软件包管理器。

通常，它们驻留在一个目录树中。它不是由系统级软件包管理器组织的，例如 /usr/local/fink 或 c:\cygwin。尽管如此，对于处理编程库的软件包管理器来说，这可能不是这种情况，因为它可能导致冲突，因为两个软件包管理器都可能破坏升级并请求“拥有”文件。