6.3. 软件包管理

6.3.2.1. 这都在我的脑袋里！

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

6.3.2.2. 安装到独立目录

这是一种最简单的软件包管理方式， 它不需要任何额外的软件来控制软件包的安装。 例如，软件包 foo-1.1 将会被安装在 /usr/pkg/foo-1.1， 然后创建一个到该目录的符号链接 /usr/pkg/foo。 在安装新版本 foo-1.2 的时候，把它安装到 /usr/pkg/foo-1.2， 然后把之前的符号链接替换，使其链接到新版本。

PATH、LD_LIBRARY_PATH、 MANPATH、INFOPATH 和 CPPFLAGS 等环境变量需要被扩充，以包含 /usr/pkg/foo。一旦软件包的数量较多， 这种架构就会变得无法管理。

6.3.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 中。

6.3.2.4. 基于时间戳的管理

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

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

6.3.2.5. 追踪安装脚本

在这种方式中，安装脚本执行的命令被记录下来。 有两种技术可以进行记录：

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

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

6.3.2.6. 创建软件包存档

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

大多数商业发行版的包管理器采用这种策略，例如 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。

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

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