diff --git a/chapter01/changelog.xml b/chapter01/changelog.xml
index cd379f697..d0a71dc34 100644
--- a/chapter01/changelog.xml
+++ b/chapter01/changelog.xml
@@ -36,6 +36,16 @@
-->
+
+ January 25, 2006
+
+
+ [matthew] - Add information about package management. Thanks to
+ the BLFS project for the text.
+
+
+
+
January 24, 2006
diff --git a/chapter06/chapter06.xml b/chapter06/chapter06.xml
index 2efc97697..2e89ad1fa 100644
--- a/chapter06/chapter06.xml
+++ b/chapter06/chapter06.xml
@@ -9,6 +9,7 @@
+
diff --git a/chapter06/introduction.xml b/chapter06/introduction.xml
index 51845cd85..8ca571197 100644
--- a/chapter06/introduction.xml
+++ b/chapter06/introduction.xml
@@ -58,16 +58,5 @@ package. Following the installation instructions, there is a list of
programs and libraries (along with brief descriptions of these) that
the package installs.
-To keep track of which package installs particular files, a package
-manager can be used. For a general overview of different styles of package
-managers, please refer to .
-For a package management method specifically geared towards LFS, we recommend .
-
-The remainder of this book is to be performed while logged in as
-user root and no longer as user lfs.
-Also, double check that $LFS is set.
-
diff --git a/chapter06/pkgmgt.xml b/chapter06/pkgmgt.xml
new file mode 100644
index 000000000..d09294da0
--- /dev/null
+++ b/chapter06/pkgmgt.xml
@@ -0,0 +1,245 @@
+
+
+ %general-entities;
+]>
+
+
+ Package Management
+
+
+ Package Management is an often requested addition to the LFS Book. A
+ Package Manager allows tracking the installation of files making it easy to
+ remove and upgrade packages. Before you begin to wonder, NO—this section
+ will not talk about nor recommend any particular package manager. What it
+ provides is a roundup of the more popular techniques and how they work. The
+ perfect package manager for you may be among these techniques or may be a
+ combination of two or more of these techniques. This section briefly mentions
+ issues that may arise when upgrading packages.
+
+ Some reasons why no package manager is mentioned in LFS or BLFS include:
+
+
+
+ Dealing with package management takes the focus away from the goals
+ of these books—teaching how a Linux system is built.
+
+
+
+ There are multiple solutions for package management, each having
+ its strengths and drawbacks. Including one that satisfies all audiences
+ is difficult.
+
+
+
+ There are some hints written on the topic of package management. Visit
+ the Hints subproject and see if one of them
+ fits your need.
+
+ As no particular package management technique is mentioned in LFS,
+ the commands in the remainder of this book must be performed while logged in
+ as user root and no longer as user
+ lfs. Also, double check that $LFS is set.
+
+
+
+ Upgrade Issues
+
+ A Package Manager makes it easy to upgrade to newer versions when they
+ are released. Generally the instructions in the LFS and BLFS Book can be
+ used to upgrade to the newer versions. Here are some points that you should
+ be aware of when upgrading packages, especially on a running system.
+
+
+
+ If one of the toolchain packages
+ (Glibc, GCC or
+ Binutils) needs to be upgraded to a newer
+ minor version, it is safer to rebuild LFS. Though you
+ may be able to get by rebuilding all the packages
+ in their dependency order, we do not recommend it. For example, if
+ glibc-2.2.x needs to be updated to glibc-2.3.x, it is safer to rebuild.
+ For micro version updates, a simple reinstallation usually works, but
+ is not guaranteed. For example, upgrading from glibc-2.3.4 to
+ glibc-2.3.5 will not usually cause any problems.
+
+
+
+ If a package containing a shared library is updated, and if the
+ name of the library changes, then all the packages dynamically linked
+ to the library need to be recompiled to link against the newer library.
+ (Note that there is no correlation between the package version and the
+ name of the library.) For example, consider a package foo-1.2.3 that
+ installs a shared library with name
+ libfoo.so.1. Say you upgrade
+ the package to a newer version foo-1.2.4 that installs a shared library
+ with name libfoo.so.2. In this
+ case, all packages that are dynamically linked to
+ libfoo.so.1 need to be
+ recompiled to link against
+ libfoo.so.2. Note that you
+ should not remove the previous libraries until the dependent packages
+ are recompiled.
+
+
+
+ If you are upgrading a running system, be on the lookout for
+ packages that use cp instead of
+ install to install files. The latter command is
+ usually safer if the executable or library is already loaded in memory.
+
+
+
+
+
+
+
+ Package Management Techniques
+
+ The following are some common package management techniques. Before
+ making a decision on a package manager, do some research on the various
+ techniques, particularly the drawbacks of the particular scheme.
+
+
+ It is All in My Head!
+
+ Yes, this is a package management technique. Some folks do not find
+ the need for a package manager because they know the packages intimately
+ and know what files are installed by each package. Some users also do not
+ need any package management because they plan on rebuilding the entire
+ system when a package is changed.
+
+
+
+ Install in Separate Directories
+
+ This is a simplistic package management that does not need any extra
+ package to manage the installations. Each package is installed in a
+ separate directory. For example, package foo-1.1 is installed in
+ /usr/pkg/foo-1.1
+ and a symlink is made from /usr/pkg/foo to
+ /usr/pkg/foo-1.1. When installing
+ a new version foo-1.2, it is installed in
+ /usr/pkg/foo-1.2 and the previous
+ symlink is replaced by a symlink to the new version.
+
+ Environment variables such as PATH,
+ LD_LIBRARY_PATH, MANPATH,
+ INFOPATH and CPPFLAGS need to be expanded to
+ include /usr/pkg/foo. For more than a few packages,
+ this scheme becomes unmanageable.
+
+
+
+ Symlink Style Package Management
+
+ This is a variation of the previous package management technique.
+ Each package is installed similar to the previous scheme. But instead of
+ making the symlink, each file is symlinked into the
+ /usr hierarchy. This removes the
+ need to expand the environment variables. Though the symlinks can be
+ created by the user to automate the creation, many package managers have
+ been written using this approach. A few of the popular ones include Stow,
+ Epkg, Graft, and Depot.
+
+ The installation needs to be faked, so that the package thinks that
+ it is installed in /usr though in
+ reality it is installed in the
+ /usr/pkg hierarchy. Installing in
+ this manner is not usually a trivial task. For example, consider that you
+ are installing a package libfoo-1.1. The following instructions may
+ not install the package properly:
+
+./configure --prefix=/usr/pkg/libfoo/1.1
+make
+make install
+
+ The installation will work, but the dependent packages may not link
+ to libfoo as you would expect. If you compile a package that links against
+ libfoo, you may notice that it is linked to
+ /usr/pkg/libfoo/1.1/lib/libfoo.so.1
+ instead of /usr/lib/libfoo.so.1
+ as you would expect. The correct approach is to use the
+ DESTDIR strategy to fake installation of the package. This
+ approach works as follows:
+
+./configure --prefix=/usr
+make
+make DESTDIR=/usr/pkg/libfoo/1.1 install
+
+ Most packages support this approach, but there are some which do
+ not. For the non-compliant packages, you may either need to manually
+ install the package, or you may find that it is easier to install some
+ problematic packages into /opt.
+
+
+
+
+ Timestamp Based
+
+ In this technique, a file is timestamped before the installation of
+ the package. After the installation, a simple use of the
+ find command with the appropriate options can generate
+ a log of all the files installed after the timestamp file was created. A
+ package manager written with this approach is install-log.
+
+ Though this scheme has the advantage of being simple, it has two
+ drawbacks. If, during installation, the files are installed with any
+ timestamp other than the current time, those files will not be tracked by
+ the package manager. Also, this scheme can only be used when one package
+ is installed at a time. The logs are not reliable if two packages are
+ being installed on two different consoles.
+
+
+
+ LD_PRELOAD Based
+
+ In this approach, a library is preloaded before installation. During
+ installation, this library tracks the packages that are being installed by
+ attaching itself to various executables such as cp,
+ install, mv and tracking the system
+ calls that modify the filesystem. For this approach to work, all the
+ executables need to be dynamically linked without the suid or sgid bit.
+ Preloading the library may cause some unwanted side-effects during
+ installation. Therefore, it is advised that one performs some tests to
+ ensure that the package manager does not break anything and logs all the
+ appropriate files.
+
+
+
+ Creating Package Archives
+
+ In this scheme, the package installation is faked into a separate
+ tree as described in the Symlink style package management. After the
+ installation, a package archive is created using the installed files.
+ This archive is then used to install the package either on the local
+ machine or can even be used to install the package on other machines.
+
+
+ This approach is used by most of the package managers found in the
+ commercial distributions. Examples of package managers that follow this
+ approach are RPM (which, incidentally, is required by the Linux
+ Standard Base Specification), pkg-utils, Debian's apt, and
+ Gentoo's Portage system. A hint describing how to adopt this style of
+ package management for LFS systems is located at .
+
+
+
+ User Based Management
+
+ This scheme, unique to LFS, was devised by Matthias Benkmann, and is
+ available from the Hints Project. In
+ this scheme, each package is installed as a separate user into the
+ standard locations. Files belonging to a package are easily identified by
+ checking the user ID. The features and shortcomings of this approach are
+ too complex to describe in this section. For the details please see the
+ hint at .
+
+
+
+
+
diff --git a/general.ent b/general.ent
index 7adfc7ef0..4c42a0687 100644
--- a/general.ent
+++ b/general.ent
@@ -1,6 +1,6 @@
-
-
+
+