经常有人请求将软件包管理加入 LFS 手册。包管理器可以跟踪文件的安装过程,简化移除或升级软件包的工作。如同处理二进制程序和库文件一样,包管理器也会处理配置文件的安装过程。在您开始想入非非前,不 —— 本节不会讨论或者推荐任何一个特定的包管理器。本节对软件包管理的流行技术及其工作原理进行综述。对您来说,完美的包管理器可能是其中的某个技术,也可能是几个技术的结合。本节还会简要介绍在升级软件包时可能遇到的问题。
LFS 或 BLFS 不介绍任何包管理器的原因包括:
处理软件包管理会偏离这两本手册的目标 —— 讲述如何构建 Linux 系统。
存在多种软件包管理的解决方案,它们各有优缺点。很难找到一种让所有读者满意的方案。
已经有人写了一些关于软件包管理这一主题的短文。您可以访问 Hints Project 并看一看是否有符合您的需求的方案。
使用包管理器可以在软件包新版本发布后容易地完成升级。一般来说,使用 LFS 或者 BLFS 手册给出的构建方法即可升级软件包。下面是您在升级时必须注意的重点,特别是升级正在运行的系统时。
如果需要升级 Glibc (例如从 Glibc-2.31 升级到 Glibc-2.32),最安全的方法是重新构建 LFS。尽管您或许能按依赖顺序重新构建所有软件包,但我们不推荐这样做。
如果更新了一个包含共享库的软件包,而且共享库的名称发生改变,那么所有动态链接到这个库的软件包都需要重新编译,以链接到新版本的库。(注意软件包的版本和共享库的名称没有关系。)
例如,考虑一个软件包 foo-1.2.3 安装了名为 libfoo.so.1
的共享库,如果您把该软件包升级到了新版本
foo-1.2.4,它安装了名为 libfoo.so.2
的共享库。那么,所有链接到 libfoo.so.1
的软件包都要重新编译以链接到 libfoo.so.2
。注意,您不能删除旧版本的库,直到将所有依赖它的软件包都重新编译完成。
以下是几种常见的软件包管理技术。在决定使用某种包管理器前,请研读这些技术,特别是要了解特定技术的不足。
没错,这是一种包管理技术。有些人觉得不需要管理软件包,因为他们十分了解软件包,知道每个软件包安装了什么文件。有的用户则计划每次有软件包发生变动时就重新构建系统,所以不需要管理软件包。
这是一种最简单的软件包管理方式,它不需要任何额外的软件来控制软件包的安装。每个软件包都被安装在单独的目录中。例如,软件包
foo-1.1 将会被安装在 /usr/pkg/foo-1.1
,然后创建一个符号链接 /usr/pkg/foo
指向 /usr/pkg/foo-1.1
。在安装新版本 foo-1.2 的时候,把它安装到
/usr/pkg/foo-1.2
,然后把之前的符号链接替换为指向新版本的符号链接。
PATH
、LD_LIBRARY_PATH
、MANPATH
、INFOPATH
和
CPPFLAGS
等环境变量需要被扩充,以包含 /usr/pkg/foo
。一旦软件包的数量较多,这种架构就会变得无法管理。
这是前一种软件包管理技术的变种。和前一种方式一样,将各个软件包同样安装在独立的目录中。但不是建立目录的符号链接,而是把其中的每个文件符号链接到
/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
中。
在这种技巧中,安装一个软件包之前,为它创建一个时间戳文件。在安装后,用一行简单的 find 命令,加上正确的参数,就能生成安装日志,包含在时间戳文件创建以后安装的所有文件。有一个采用这个方案的包管理器叫做 install-log。
尽管这种方式很简单,但它有两个缺点。如果在安装过程中,某些文件没有以当前时间作为时间戳安装,它们就不能被包管理器跟踪。另外,只有每次只安装一个软件包时才能使用这种技术。如果在两个终端中同时安装两个不同的软件包,它们的安装日志就不可靠了。
在这种方式中,安装脚本执行的命令被记录下来。有两种技术可以进行记录:
在安装前设置 LD_PRELOAD
环境变量,将其指向一个库以在安装过程中预加载它。在安装过程中,这个库附加在 cp、install、mv
等可执行文件上,跟踪修改文件系统的系统调用。如果要使用这种方法,所有需要跟踪的可执行文件必须是动态链接的,且没有设定 suid 和
sgid
位。预加载动态库可能在安装过程中导致不希望的副作用。因此,建议在实际使用前进行一些测试,以确保包管理器不会造成破坏,并且记录了所有应该记录的文件。
第二种技术是使用 strace,它能够记录安装脚本执行过程中的所有系统调用。
在这种架构中,软件包被伪装安装到一个独立的目录树中,就像软链接风格的软件包管理那样。在安装后,使用被安装的文件创建一个软件包档案。它可以被用来在本地机器甚至其他机器上安装该软件包。
大多数商业发行版的包管理器采用这种策略。例如 RPM (值得一提的是,它被 Linux Standard Base 规则所要求)、pkg-utils、Debian 的 apt,以及 Gentoo 的 Portage 系统等。LFS Hint 中的一篇短文描述了如何为 LFS 系统适用这种管理方式:http://www.linuxfromscratch.org/hints/downloads/files/fakeroot.txt。
创建包含依赖关系信息的软件包文件十分复杂,超出了 LFS 的范畴。
Slackware 使用一个基于 tar 的系统创建软件包档案。和更复杂的包管理器不同,该系统有意地没有涉及软件包依赖关系。如果想了解 Slackware 包管理器的详细信息,阅读 http://www.slackbook.org/html/package-management.html。
这种架构是 LFS 特有的,由 Matthias Benkmann 提出,可以在 Hints Project 查阅。在该架构中,每个软件包都由一个单独的用户安装到标准位置。只要检查文件所有者,就能找出属于一个软件包的所有文件。它的优缺点十分复杂,无法在本节讨论。如果想详细了解,请访问 http://www.linuxfromscratch.org/hints/downloads/files/more_control_and_pkg_man.txt 阅读。
LFS 系统的一项优势是,没有依赖于磁盘系统中文件位置的文件。将构建好的 LFS
系统复制到另一台具有相同硬件架构的计算机很简单,只要用 tar 命令把包含根目录的 LFS 分区打包
(未压缩的情况下,一个基本的 LFS 系统需要 250 MB),然后通过网络或者 CD-ROM
复制到新的系统上,再展开即可。这时,个别配置文件需要修改。可能需要更新的配置文件有:/etc/hosts
,/etc/fstab
,/etc/passwd
,/etc/group
,/etc/shadow
,以及 /etc/ld.so.conf
。
由于系统硬件和原始内核配置的区别,可能需要为新系统重新配置并构建内核。
有一些报告反映称,在架构相近但不完全一致的计算机之间拷贝 LFS 系统时出现问题。例如,Intel 系统使用的指令集和 AMD 处理器不完全相同,且较新的处理器可能包含旧处理器没有的指令。
最后,按照第 10.4 节 “设定引导过程”中的说明,为新系统配置引导加载器。