Index: introduction/important/important.xml
===================================================================
--- introduction/important/important.xml	(revision dffeaee13e01f8efee4d358c2ca52ec4bfb4f4cc)
+++ introduction/important/important.xml	(revision 3d760b6a36f40f07bcb723ebfa2d916cc1805cee)
@@ -3,4 +3,5 @@
 <title>Important Information</title>
 
+&intro-important-pkgmgt;
 &intro-important-unpacking;
 &intro-important-position;
Index: introduction/important/pkgmgt.xml
===================================================================
--- introduction/important/pkgmgt.xml	(revision 3d760b6a36f40f07bcb723ebfa2d916cc1805cee)
+++ introduction/important/pkgmgt.xml	(revision 3d760b6a36f40f07bcb723ebfa2d916cc1805cee)
@@ -0,0 +1,199 @@
+<sect1 id="intro-important-pkgmgt">
+<?dbhtml filename="pkgmgt.html" dir="introduction"?>
+<title>Package Management</title>
+
+<para>Package Management has been one of the often requested addition
+to the <acronym>LFS</acronym> Book. A Package Manager allows tracking
+the installation of files making it easy to remove and upgrade packages.
+And before you begin to wonder, NO - this section does not talk about any
+particular package manager, nor does it recommend one. 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 also mentions
+in brief about some upgrade issues.</para>
+
+<para>Some reasons why no package manager is mentioned in <acronym>LFS</acronym>
+or <acronym>BLFS</acronym>:</para>
+
+<itemizedlist>
+<listitem><para>Dealing with package management takes the focus away from
+the goals of these books - Teaching how a Linux System is built.</para></listitem>
+<listitem><para>There are multiple solutions for package management, each having
+its strengths and drawbacks.</para></listitem>
+</itemizedlist>
+
+<para>There are some hints written on the topic of package management. Visit
+the <ulink url="http://www.linuxfromscratch.org/hints/">Hints subproject</ulink>
+to find if one of them fits your need.</para>
+
+
+<sect2>
+<title>Upgrade Issues</title>
+
+<para>Following are some points that you should be aware of when upgrading
+pacakges, especially on a running system.</para>
+
+<itemizedlist>
+<listitem><para>It is recommended that if one of the toolchain package (glibc, gcc,
+binutils) needs to be upgraded to a newer minor vesion, it is safer to rebuild
+<acronym>LFS</acronym>. Though you <emphasis>may</emphasis> be able to get by by
+rebuilding all the packages in their dependency order. We do not recommend the
+latter. 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.1 to glibc-2.3.2 will not
+usually cause any problems.</para></listitem>
+<listitem><para>If a package containing a shared library is updated, and if the
+soname 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 corelation between the package version and the soname of the library.) For
+example, consider a package foo-1.2.3 that installs a shared library with soname
+<filename>libfoo.so.1</filename>. Say you upgrade the package to a newer version
+foo-1.2.4 that installs a shared library with soname <filename>libfoo.so.2</filename>.
+In this case, all packages that are dynamically linked to <filename>libfoo.so.1</filename>
+need to be recompiled to link against <filename>libfoo.so.2</filename>. Note that
+you should not remove the previous libraries till the dependent packages are
+recompiled.</para></listitem>
+<listitem><para>If you are upgrading a running system, be on the lookout for
+packages that use <command>cp</command> instead of <command>install</command> to
+install files. The latter command is usually safer if the executable or library
+is already loaded in memory.</para></listitem>
+</itemizedlist>
+
+</sect2>
+
+
+<sect2>
+<title>Package Management Techniques</title>
+
+<para>The following are some common package management techniques.</para>
+
+<sect3>
+<title>Its all in my head!</title>
+
+<para>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 <acronym>LFS</acronym>
+when a package is changed.</para>
+
+</sect3>
+
+<sect3>
+<title>Install in seperate directories</title>
+
+<para>This is a simplistic package management that does not need any extra package
+to manage the installations. Each package is installed in a seperate directory.
+For example, package foo-1.1 is installed in <filename>/usr/pkg/foo-1.1</filename>
+and a symlink is made from <filename>/usr/pkg/foo</filename> to
+<filename>/usr/pkg/foo-1.1</filename>. When installing a new version foo-1.2,
+it is installed in <filename>/usr/pkg/foo-1.2</filename> and the previous
+symlink is replaced by a symlink to the new vesion.</para>
+
+<para>The environment variables such as those
+mentioned in <xref linkend="appendices-generic"/> need to be expanded to
+include <filename>/usr/pkg/foo</filename>. For more than a few packages,
+this scheme becomes unmanagable.</para>
+
+</sect3>
+
+<sect3>
+<title>Symlink style package management</title>
+
+<para>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 <filename>/usr</filename> 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 on this approach.
+Few of the popular ones are Stow, Epkg, Graft, and Depot.</para>
+
+<para>The installation needs to be faked, so that the package thinks that it is
+installed in <filename>/usr</filename> though in reality it is installed in
+<filename>/ust/pkg</filename> hierachy. 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:</para>
+
+<screen><userinput><command>./configure --prefix=/usr/pkg/libfoo/1.1 &amp;&amp;
+make &amp;&amp;
+make install</command></userinput></screen>
+
+<para>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 <filename>/usr/pkg/libfoo/1.1/lib/libfoo.so.1</filename>
+instead of <filename>/usr/lib/libfoo.so.1</filename> as you would expect. The correct
+approach is to use <envar>DESTDIR</envar> strategy to fake installation of the package.
+This approach works as follows:</para>
+
+<screen><userinput><command>./configure --prefix=/usr &amp;&amp;
+make &amp;&amp;
+make DESTDIR=/usr/pkg/libfoo/1.1 install</command></userinput></screen>
+
+<para>Most of the packages do 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
+<filename>/opt</filename>.</para>
+
+</sect3>
+
+<sect3>
+<title>Timestamp based</title>
+
+<para>In this technique, a file is timestamped before the installation of the package.
+After the installation, a simple use of the <command>find</command> 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.</para>
+
+<para>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.</para>
+
+</sect3>
+
+<sect3>
+<title>LD_PRELOAD based</title>
+
+<para>In this approach, a library is preloaded before installation and during
+installation, this library tracks the packages that are being installed by
+attaching itself to various executables such as <command>cp</command>,
+<command>install</command>, <command>mv</command> and tracking the system
+calls that modify the filesystem. For this approach to work, all the executables
+need to be dymanically linked without the suid or sgid bit. Preloading the
+library may cause some unwanted side-effects during installation.</para>
+
+</sect3>
+
+<sect3>
+<title>Creating Package Archives</title>
+
+<para>In this scheme, the package installation is faked into a seperate
+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.</para>
+
+<para>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, pkg-utils, Debian's apt, Gentoo's Portage system.</para>
+
+</sect3>
+
+<sect3>
+<title>User Based Management</title>
+
+<para>This scheme, that is unique to <acronym>LFS</acronym>, was
+devised by Matthias Benkmann, and is available from the <ulink
+url="http://www.linuxfromscratch.org/hints/">Hints Project</ulink>.
+In this scheme, each package is installed as a seperate 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 <ulink
+url="http://www.linuxfromscratch.org/hints/downloads/files/more_control_and_pkg_man.txt"/>.</para>
+
+</sect3>
+
+</sect2>
+
+
+</sect1>
Index: introduction/introduction.ent
===================================================================
--- introduction/introduction.ent	(revision dffeaee13e01f8efee4d358c2ca52ec4bfb4f4cc)
+++ introduction/introduction.ent	(revision 3d760b6a36f40f07bcb723ebfa2d916cc1805cee)
@@ -14,4 +14,5 @@
 
 <!ENTITY intro-important SYSTEM "important/important.xml">
+<!ENTITY intro-important-pkgmgt SYSTEM "important/pkgmgt.xml">
 <!ENTITY intro-important-unpacking SYSTEM "important/unpacking.xml">
 <!ENTITY intro-important-position SYSTEM "important/position.xml">
Index: introduction/welcome/credits.xml
===================================================================
--- introduction/welcome/credits.xml	(revision dffeaee13e01f8efee4d358c2ca52ec4bfb4f4cc)
+++ introduction/welcome/credits.xml	(revision 3d760b6a36f40f07bcb723ebfa2d916cc1805cee)
@@ -38,4 +38,7 @@
 
 <listitem><para>Chapter 02: Going beyond <acronym>BLFS</acronym>: <emphasis>
+Tushar Teredesai</emphasis>.</para></listitem>
+
+<listitem><para>Chapter 02: Package Management: <emphasis>
 Tushar Teredesai</emphasis>.</para></listitem>
 
