8.2. 软件包管理

经常有人请求将软件包管理加入 LFS 手册。包管理器跟踪文件的安装过程,简化移除或升级软件包的工作。一个好的包管理器还会特殊处理配置文件,以在重新安装或升级软件包时保留用户配置。在您开始想入非非前,不 —— 本节不会讨论或者推荐任何一个特定的包管理器。本节对软件包管理的流行技术及其工作原理进行综述。对您来说,完美的包管理器可能是其中的某个技术,也可能是几个技术的结合。本节还会简要介绍在升级软件包时可能遇到的问题。

LFS 或 BLFS 不介绍任何包管理器的原因包括:

已经有人写了一些关于软件包管理这一主题的短文。您可以访问 Hints Project 并看一看是否有符合您的需求的方案。

8.2.1. 升级问题

使用包管理器可以在软件包新版本发布后容易地完成升级。一般来说,使用 LFS 或者 BLFS 手册给出的构建方法即可升级软件包。下面是您在升级时必须注意的重点,特别是升级正在运行的系统时。

  • 如果需要升级 Linux 内核 (例如,从 5.10.17 升级到 5.10.18 或 5.11.1),则不需要重新构建其他任何软件包。因为内核态与用户态的接口十分清晰,系统仍然能够继续正常工作。特别地,在升级内核时,不需要一同更新 Linux API 头文件。重新引导系统即可使用升级后的内核。

  • 如果需要将 Glibc 升级到一个新版本 (例如,从 Glibc-2.36 升级到 Glibc-2.40),则需要进行一些额外操作,以防止损坏系统。详见第 8.5 节 “Glibc-2.40”

  • 如果更新了一个包含共享库的软件包,而且共享库的名称发生改变,那么所有动态链接到这个库的软件包都需要重新编译,以链接到新版本的库。(注意软件包的版本和共享库的名称没有关系。) 例如,考虑一个软件包 foo-1.2.3 安装了名为 libfoo.so.1 的共享库,如果您把该软件包升级到了新版本 foo-1.2.4,它安装了名为 libfoo.so.2 的共享库。那么,所有链接到 libfoo.so.1 的软件包都要重新编译以链接到 libfoo.so.2。注意,您不能删除旧版本的库,直到将所有依赖它的软件包都重新编译完成。

  • 如果一个软件包 (直接或间接地) 链接到同一共享库的旧名称和新名称 (例如,同时链接到 libfoo.so.2libbar.so.1,而后者又链接到 libfoo.so.3),这个软件包可能无法正常工作,这是由于不同版本的共享库可能对同一符号名提供不兼容的定义。这种情况可能由于在更新提供共享库的软件包后,重新编译一部分 (而非所有) 链接到旧的共享库的软件包而出现。为了避免这种问题,用户需要在共享库名称被更新时,尽快重新构建所有链接到该共享库的软件包。

  • 如果更新了一个包含共享库的软件包,且共享库的名称没有改变,但是库文件的版本号降低了 (例如,库的名称保持 libfoo.so.1 不变,但是库文件名由 libfoo.so.1.25 变为 libfoo.so.1.24),则需要删除旧版本软件包安装的库文件 (对于上述示例,需要删除 libfoo.so.1.25)。否则,ldconfig 命令 (可能是您通过命令行执行,也可能由一些软件包的安装过程自动执行) 会将符号链接 libfoo.so.1 的目标重设为旧版本的库文件,因为它版本号更大,看上去更。在不得不降级软件包,或者软件包作者更改库文件版本号格式时,可能出现这种问题。

  • 如果更新了一个包含共享库的软件包,且共享库的名称没有改变,但是这次更新修复了一个严重问题 (特别是安全缺陷),则要重新启动所有链接到该库的程序。在更新软件包的过程完成后,以 root 身份,运行以下命令,即可列出所有正在使用旧版本共享库的进程 (将 libfoo 替换成库名):

    grep -l 'libfoo.*deleted' /proc/*/maps | tr -cd 0-9\\n | xargs -r ps u

    如果正在使用 OpenSSH 访问系统,且它链接到了被更新的库,则需要重启 sshd 服务,登出并重新登录,然后再次运行上述命令,确认没有进程使用被删除的库文件。

    如果 systemd 守护进程 (以 PID 1 运行) 链接到了被更新的库,可以在不重启系统的前提下重启它:以 root 用户身份,运行 systemctl daemon-reexec 命令即可。

  • 如果一个可执行程序或共享库被覆盖,正在使用该程序或库中的代码或数据的进程可能崩溃。正确的,不会导致进程崩溃的更新程序或共享库的方法是:先删除旧版本,再安装新版本。Coreutils 提供的 install 已经实现了这一过程,多数软件包使用该命令安装二进制文件和库。这意味着在更新软件包时通常不会遇到这个问题。然而,一些软件包 (如 BLFS 中的 SpiderMonkey) 的安装过程会简单覆盖已经存在的文件并导致进程崩溃,因此在进行更新前,最好保存工作并关闭不需要的,正在运行的进程。

8.2.2. 软件包管理技术

以下是几种常见的软件包管理方案。在决定使用某种包管理器前,请研读这些方案,特别是要了解每种方案的不足。

8.2.2.1. 这都在我的脑袋里!

没错,这是一种包管理技术。有些人不需要包管理器,因为他们十分了解软件包,知道每个软件包安装了什么文件。有的用户则计划每次有软件包发生变动时就重新构建系统,所以不需要管理软件包。

8.2.2.2. 安装到独立目录

这是一种最简单的软件包管理方式,它不需要控制软件包安装的专用程序。每个软件包都被安装在单独的目录中。例如,软件包 foo-1.1 将会被安装在 /opt/foo-1.1,然后创建一个符号链接 /opt/foo 指向 /opt/foo-1.1。在安装新版本 foo-1.2 的时候,把它安装到 /opt/foo-1.2,然后把之前的符号链接替换为指向新版本的符号链接。

PATHMANPATHINFOPATHPKG_CONFIG_PATHCPPFLAGSLDFLAGS 等环境变量,以及配置文件 /etc/ld.so.conf 可能需要被扩充,以包含 /opt/foo-x.y

BLFS 手册使用这种模式安装一些非常庞大的软件包,这样能更容易地更新它们。一旦用这种方式安装了比较多的软件包,这种模式就会变得难以控制。另外,一些软件包 (如 Linux API 头文件和 Glibc) 在使用这种方式安装时可能无法正常工作。永远不要对整个系统的所有软件包使用这种模式。

8.2.2.3. 符号链接风格的软件包管理

这是前一种软件包管理技术的变种。和前一种方式一样,将各个软件包同样安装在独立的目录中。但不是使用软件包的名称建立符号链接,而是将软件包中的每个文件符号链接到 /usr 目录树中对应的位置。这样就不需要修改环境变量。虽然这些符号链接可以由用户自己创建,但已经有许多包管理器能够自动化这一过程。一些流行的包管理器如 Stow、Epkg、Graft 和 Depot 使用这种管理方式。

需要欺骗安装脚本,使得软件包认为它处于 /usr 中,尽管它实际上被安装在 /usr/pkg 目录结构中。这种安装过程往往是超出常规的。例如,考虑安装软件包 libfoo-1.1。下面的方法可能不能正确安装该软件包:

./configure --prefix=/usr/pkg/libfoo/1.1
make
make install

尽管安装过程本身可以顺利进行,但依赖于它的软件包可能不会像您期望的那样链接 libfoo 库。如果要编译一个依赖于 libfoo 的软件包,您可能发现它链接到了 /usr/pkg/libfoo/1.1/lib/libfoo.so.1 而不是您期望的 /usr/lib/libfoo.so.1。正确的做法是使用 DESTDIR 环境变量转移安装位置。就像下面这样做:

./configure --prefix=/usr
make
make DESTDIR=/usr/pkg/libfoo/1.1 install

多数软件包可以这样安装,但有些不能。对于那些不兼容的软件包,您要么亲自动手安装,要么更简单地把一些出问题的软件包安装在 /opt 中。

8.2.2.4. 基于时间戳的方案

在这种方案中,安装一个软件包之前,创建一个时间戳文件。在安装后,用一行简单的 find 命令,加上正确的参数,就能生成安装日志,包含在时间戳文件创建以后安装的所有文件。有一个采用这个方案的包管理器叫做 install-log。

尽管这种方式很简单,但它有两个缺点。如果在安装过程中,某些文件没有以当前时间作为时间戳安装,它们就不能被包管理器跟踪。另外,只有每次只安装一个软件包时才能使用这种技术。如果在两个控制台中同时安装两个不同的软件包,它们的安装日志就不可靠了。

8.2.2.5. 追踪安装脚本

在这种方案中,安装脚本执行的命令被记录下来。有两种技巧可以用于记录:

在安装前设置 LD_PRELOAD 环境变量,将其指向一个库以在安装过程中预加载它。在安装过程中,这个库附加在 cpinstallmv 等可执行文件上,跟踪修改文件系统的系统调用。如果要使用这种方法,所有需要跟踪的可执行文件必须是动态链接的,且没有设定 suid 和 sgid 位。预加载动态库可能在安装过程中导致不希望的副作用。因此,最好在实际使用前进行一些测试,以确保包管理器不会造成破坏,并且记录了所有应该记录的文件。

第二种技巧是使用 strace,它能够记录安装脚本执行过程中的所有系统调用。

8.2.2.6. 创建软件包档案

在这种方案中,软件包被伪装安装到一个独立的目录树中,就像软链接风格的软件包管理那样。在安装后,使用被安装的文件创建一个软件包档案。它可以被用来在本地机器甚至其他机器上安装该软件包。

大多数商业发行版的包管理器采用这种策略。例如 RPM (值得一提的是,它被 Linux Standard Base 规则所要求)、pkg-utils、Debian 的 apt,以及 Gentoo 的 Portage 系统等。LFS Hint 中的一篇短文描述了如何为 LFS 系统适用这种管理方式:https://www.linuxfromscratch.org/hints/downloads/files/fakeroot.txt

创建包含依赖关系信息的软件包文件十分复杂,超出了 LFS 的范畴。

Slackware 使用一个基于 tar 的系统创建软件包档案。和更复杂的包管理器不同,该系统有意地没有涉及软件包依赖关系。如果想了解 Slackware 包管理器的详细信息,阅读 https://www.slackbook.org/html/package-management.html

8.2.2.7. 基于用户的软件包管理

这种架构是 LFS 特有的,由 Matthias Benkmann 提出,可以在 Hints Project 查阅。在该架构中,每个软件包都由一个单独的用户安装到标准位置。只要检查文件所有者,就能找出属于一个软件包的所有文件。它的优缺点十分复杂,无法在本节讨论。如果想详细了解,请访问 https://www.linuxfromscratch.org/hints/downloads/files/more_control_and_pkg_man.txt 阅读。

8.2.3. 在多个系统上部署 LFS

LFS 系统的一项优势是,没有依赖于磁盘系统中文件位置的文件。将构建好的 LFS 系统复制到另一台具有相同硬件架构的计算机很简单,只要用 tar 命令把包含根目录的 LFS 分区打包 (未压缩的情况下,一个基本的 LFS 系统需要 900 MB),然后通过网络或者 CD-ROM 复制到新的系统上,再展开即可。之后,个别配置文件需要修改。可能需要更新的配置文件有:/etc/hosts/etc/fstab/etc/passwd/etc/group/etc/shadow,以及 /etc/ld.so.conf

由于系统硬件和内核配置的区别,可能需要为新系统重新配置并构建内核。

[注意]

注意

有一些报告反映称,在架构相近但不完全一致的计算机之间拷贝 LFS 系统时出现问题。例如,Intel 系统使用的指令集和 AMD 处理器不完全相同,且较新的处理器可能提供旧处理器没有的指令。

最后,按照第 10.4 节 “使用 GRUB 设定引导过程”中的说明,为新系统配置引导加载器。