包管理器的进化

Steve Ovens 的头像

·

·

·

9,702 次阅读

包管理器在 Linux 软件管理中扮演了重要角色。这里对一些主要的包管理器进行了对比。

今天,每个可计算设备都会使用某种软件来完成预定的任务。在软件开发的上古时期,为了找出软件中的“虫”和其它缺陷,软件会被严格的测试。在近十年间,软件被通过互联网来频繁分发,以试图通过持续不断的安装新版本的软件来解决软件的缺陷问题。在很多情况下,每个独立的应用软件都有其自带的更新器。而其它一些软件则让用户自己去搞明白如何获取和升级软件。

Linux 较早采用了维护一个中心化的软件仓库来发布软件更新这种做法,用户可以在这个软件仓库里查找并安装软件。在这篇文章里, 笔者将回顾在 Linux 上的如何进行软件安装的历史,以及现代操作系统如何保持更新以应对软件安全漏洞(CVE)不断的曝光。

那么在包管理器出现之前在 Linux 上是如何安装软件的呢?

曾几何时,软件都是通过 FTP 或邮件列表(LCTT 译注:即通过邮件列表发布源代码的补丁包)来分发的(最终这些发布方式在互联网的迅猛发展下都演化成为一个个现今常见的软件发布网站)。(一般在一个 tar 文件中)只有一个非常小的文件包含了创建二进制的说明。你需要做的是先解压这个包,然后仔细阅读当中的 README 文件, 如果你的系统上恰好有 GCC(LCTT 译注:GNU C Compiler)或者其它厂商的 C 编译器的话,你得首先运行 ./configure 脚本,并在脚本后添加相应的参数,如库函数的路径、创建可执行文件的路径等等。除此之外,这个配置过程也会检查你操作系统上的软件依赖是否满足安装要求。如果缺失了任何主要的依赖,该配置脚本会退出不再继续安装,直到你满足了该依赖。如果该配置脚本正常执行完毕,将会创建一个 Makefile 文件。

当有了一个 Makefile 文件时, 你就可以接下去执行 make 命令(该命令由你所使用的编译器提供)。make 命令也有很多参数,被称为 make 标识 flag ,这些标识能为你的系统优化最终生成出来的二进制可执行文件。在计算机世界的早期,这些优化是非常重要的,因为彼时的计算机硬件正在为了跟上软件迅速的发展而疲于奔命。今日今时,编译标识变得更加通用而不是为了优化哪些具体的硬件型号,这得益于现代硬件和现代软件相比已经变得成本低廉,唾手可得。

最后,在 make 完成之后, 你需要运行 make install (或 sudo make install)(LCTT 译注:依赖于你的用户权限) 来“真正”将这个软件安装到你的系统上。可以想象,为你系统上的每一个软件都执行上述的流程将是多么无聊费时,更不用说如果更新一个已经安装的软件将会多复杂,多么需要精力投入。(LCTT 译注:上述流程也称 CMMI 安装, 即Configure、Make、Make Install)

那么软件包是什么?

软件包 package (LCTT 译注:下文简称“包”)这个概念是用来解决在软件安装、升级过程中的复杂性的。包将软件安装升级中需要的多个数据文件合并成一个单独的文件,这将便于传输和(通过压缩文件来)减小存储空间(LCTT 译注:减少存储空间这一点在现在已经不再重要),包中的二进制可执行文件已根据开发者所选择的编译标识预编译。包本身包括了所有需要的元数据,如软件的名字、软件的说明、版本号,以及要运行这个软件所需要的依赖包等等。

不同流派的 Linux 发行版都创造了它们自己的包格式,其中最常用的包格式有:

  • .deb:这种包格式由 Debian、Ubuntu、Linux Mint 以及其它的变种使用。这是最早被发明的包类型。
  • .rpm:这种包格式最初被称作 红帽包管理器 Red Hat Package Manager (LCTT 译注: 取自英文的首字母)。使用这种包的 Linux 发行版有 Red Hat、Fedora、SUSE 以及其它一些较小的发行版。
  • .tar.xz:这种包格式只是一个软件压缩包而已,这是 Arch Linux 所使用的格式。

尽管上述的包格式自身并不能直接管理软件的依赖问题,但是它们的出现将 Linux 软件包管理向前推进了一大步。

软件仓库到底是什么?

多年以前(当智能电话还没有像现在这样流行时),非 Linux 世界的用户是很难理解软件仓库的概念的。甚至今时今日,大多数完全工作在 Windows 下的用户还是习惯于打开浏览器,搜索要安装的软件(或升级包),下载然后安装。但是,智能电话传播了软件“商店”(LCTT 译注: 对应 Linux 里的软件仓库)这样一个概念。智能电话用户获取软件的方式和包管理器的工作方式已经非常相近了。些许不同的是,尽管大多数软件商店还在费力美化它的图形界面来吸引用户,大多数 Linux 用户还是愿意使用命令行来安装软件。总而言之,软件仓库是一个中心化的可安装软件列表,上面列举了在当前系统中预先配置好的软件仓库里所有可以安装的软件。下面我们举一些例子来说在各个不同的 Linux 发行版下如何在对应的软件仓库里搜寻某个特定的软件(输出有截断)。

在 Arch Linux 下使用 aurman

user@arch ~ $  aurman -Ss kate

extra/kate 18.04.2-2 (kde-applications kdebase)
    Advanced Text Editor
aur/kate-root 18.04.0-1 (11, 1.139399)
    Advanced Text Editor, patched to be able to run as root
aur/kate-git r15288.15d26a7-1 (1, 1e-06)
    An advanced editor component which is used in numerous KDE applications requiring a text editing component

在 CentOS 7 下使用 yum

[user@centos ~]$ yum search kate

kate-devel.x86_64 : Development files for kate
kate-libs.x86_64 : Runtime files for kate
kate-part.x86_64 : Kate kpart plugin

在 Ubuntu 下使用 apt

user@ubuntu ~ $ apt search kate
Sorting... Done
Full Text Search... Done

kate/xenial 4:15.12.3-0ubuntu2 amd64
  powerful text editor

kate-data/xenial,xenial 4:4.14.3-0ubuntu4 all
  shared data files for Kate text editor

kate-dbg/xenial 4:15.12.3-0ubuntu2 amd64
  debugging symbols for Kate

kate5-data/xenial,xenial 4:15.12.3-0ubuntu2 all
  shared data files for Kate text editor

最好用的包管理器有哪些?

如上示例的输出,包管理器用来和相应的软件仓库交互,获取软件的相应信息。下面对它们做一个简短介绍。

基于 PRM 包格式的包管理器

更新基于 RPM 的系统,特别是那些基于 Red Hat 技术的系统,有着非常有趣而又详实的历史。实际上,现在的 YUM 版本(用于 企业级发行版)和 DNF(用于社区版)就融合了好几个开源项目来提供它们现在的功能。

Red Hat 最初使用的包管理器,被称为 RPM 红帽包管理器 Red Hat Package Manager ),时至今日还在使用着。不过,它的主要作用是安装本地的 RPM 包,而不是去在软件仓库搜索软件。后来开发了一个叫 up2date 的包管理器,它被用来通知用户包的最新更新,还能让用户在远程仓库里搜索软件并便捷的安装软件的依赖。尽管这个包管理器尽职尽责,但一些社区成员还是感觉 up2date 有着明显的不足。

现在的 YUM 来自于好几个不同社区的努力。1999-2001 年一群在 Terra Soft Solution 的伙计们开发了 黄狗更新器 Yellowdog Updater (YUP),将其作为 Yellow Dog Linux 图形安装器的后端。 杜克大学 Duke University 喜欢这个主意就决定去增强它的功能,它们开发了 黄狗更新器–修改版 Yellowdog Updater, Modified (YUM),这最终被用来帮助管理杜克大学的 Red Hat 系统。Yum 壮大的很快,到 2005 年,它已经被超过一半的 Linux 市场所采用。今日,几乎所有的使用 RPM 的的 Linux 都会使用 YUM 来进行包管理(当然也有一些例外)。

使用 YUM

为了能让 YUM 正常工作,比如从一个软件仓库里下载和安装包,仓库说明文件必须放在 /etc/yum.repos.d/ 目录下且必须以 .repo 作为扩展名。如下是一个示例文件的内容:

[local_base]
name=Base CentOS  (local)
baseurl=http://7-repo.apps.home.local/yum-repo/7/
enabled=1
gpgcheck=0

这是笔者本地仓库之一,这也是为什么 gpgcheck 值为 0 的原因。如果这个值为 1 的话,每个包都需要被密钥签名,相应的密钥(的公钥)也要导入到安装软件的系统上。因为这个软件仓库是笔者本人维护的且笔者信任这个仓库里的包,所以就不去对它们一一签名了。

当一个仓库文件准备好时,你就能开始从远程软件仓库开始安装文件了。最基本的命令是 yum update,这将会更新所有已安装的包。你也不需要用特殊的命令来更新仓库本身,所有这一切都已自动完成了。运行命令示例如下:

[user@centos ~]$ sudo yum update
Loaded plugins: fastestmirror, product-id, search-disabled-repos, subscription-manager
local_base                             | 3.6 kB  00:00:00    
local_epel                             | 2.9 kB  00:00:00    
local_rpm_forge                        | 1.9 kB  00:00:00    
local_updates                          | 3.4 kB  00:00:00    
spideroak-one-stable                   | 2.9 kB  00:00:00    
zfs                                    | 2.9 kB  00:00:00    
(1/6): local_base/group_gz             | 166 kB  00:00:00    
(2/6): local_updates/primary_db        | 2.7 MB  00:00:00    
(3/6): local_base/primary_db           | 5.9 MB  00:00:00    
(4/6): spideroak-one-stable/primary_db |  12 kB  00:00:00    
(5/6): local_epel/primary_db           | 6.3 MB  00:00:00    
(6/6): zfs/x86_64/primary_db           |  78 kB  00:00:00    
local_rpm_forge/primary_db             | 125 kB  00:00:00    
Determining fastest mirrors
Resolving Dependencies
--> Running transaction check

如果你确定想让 YUM 在执行任何命令时不要停下来等待用户输入,你可以命令里放 -y 标志,如 yum update -y

安装一个新包很简单。首先,用 yum search 搜索包的名字。

[user@centos ~]$ yum search kate

artwiz-aleczapka-kates-fonts.noarch : Kates font in Artwiz family
ghc-highlighting-kate-devel.x86_64 : Haskell highlighting-kate library development files
kate-devel.i686 : Development files for kate
kate-devel.x86_64 : Development files for kate
kate-libs.i686 : Runtime files for kate
kate-libs.x86_64 : Runtime files for kate
kate-part.i686 : Kate kpart plugin

当你找到你要安装的包后,你可以用 sudo yum install kate-devel -y 来安装。如果你安装了你不需要的软件,可以用 sudo yum remove kdate-devel -y 来从系统上删除它,默认情况下,YUM 会删除软件包以及它的依赖。

有些时候你甚至都不清楚要安装的包的名称,你只知道某个实用程序的名字。(LCTT 译注:可以理解实用程序是安装包的子集)。例如,你想找实用程序 updatedb(它是用来创建/更新由 locate 命令所使用的数据库的),直接试图安装 updatedb 会返回下面的结果:

[user@centos ~]$ sudo yum install updatedb
Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile
No package updatedb available.
Error: Nothing to do

你可以搜索实用程序来自哪个包:

[user@centos ~]$ yum whatprovides *updatedb
Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile

bacula-director-5.2.13-23.1.el7.x86_64 : Bacula Director files
Repo        : local_base
Matched from:
Filename    : /usr/share/doc/bacula-director-5.2.13/updatedb

mlocate-0.26-8.el7.x86_64 : An utility for finding files by name
Repo        : local_base
Matched from:
Filename    : /usr/bin/updatedb

笔者在前面使用星号的原因是 yum whatprovides 使用路径去匹配文件。笔者不确定文件在哪里,所以使用星号去指代任意路径。

当然 YUM 还有很多其它的可选项。这里笔者希望你能够自己查看 YUM 的手册来找到其它额外的可选项。

时髦的 Yum Dandified Yum (DNF)是 YUM 的下一代接班人。从 Fedora 18 开始被作为包管理器引入系统,不过它并没有被企业版所采用,所以它只在 Fedora(以及变种)上占据了主导地位。DNF 的用法和 YUM 几乎一模一样,它主要是用来解决性能问题、晦涩无说明的API、缓慢/不可靠的依赖解析,以及偶尔的高内存占用。DNF 是作为 YUM 的直接替代品来开发的,因此这里笔者就不重复它的用法了,你只用简单的将 yum 替换为 dnf 就行了。

使用 Zypper

Zypper 是用来管理 RPM 包的另外一个包管理器。这个包管理器主要用于 SUSE(和 openSUSE),在MeeGoSailfish OSTizen 上也有使用。它最初开发于 2006 年,已经经过了多次迭代。除了作为系统管理工具 YaST 的后端和有些用户认为它比 YUM 要快之外也没有什么好多说的。

Zypper 使用与 YUM 非常相像。它被用来搜索、更新、安装和删除包,简单的使用命令如下:

zypper search kate
zypper update
zypper install kate
zypper remove kate

主要的不同来自于使用 Zypper 的系统在添加软件仓库的做法上,Zypper 使用包管理器本身来添加软件仓库。最通用的方法是通过一个 URL,但是 Zypper 也支持从仓库文件里导入。

suse:~ # zypper addrepo http://download.videolan.org/pub/vlc/SuSE/15.0 vlc
Adding repository 'vlc' [done]
Repository 'vlc' successfully added

Enabled     : Yes
Autorefresh : No
GPG Check   : Yes
URI         : http://download.videolan.org/pub/vlc/SuSE/15.0
Priority    : 99

你也能用相似的手段来删除软件仓库:

suse:~ # zypper removerepo vlc
Removing repository 'vlc' ...................................[done]
Repository 'vlc' has been removed.

使用 zypper repos 命令来查看当前系统上的软件仓库的状态:


suse:~ # zypper repos
Repository priorities are without effect. All enabled repositories share the same priority.

#  | Alias                     | Name                                    | Enabled | GPG Check | Refresh
||-      | -      | -      | -      | ||

via: <https://opensource.com/article/18/7/evolution-package-managers>

作者:[Steve Ovens](https://opensource.com/users/stratusss) 选题:[lujun9972](https://github.com/lujun9972) 译者:[DavidChenLiang](https://github.com/davidchenliang) 校对:[wxy](https://github.com/wxy)

本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注