cvs commit: BLFS/BOOK/introduction/welcome credits.xml

tushar at tushar at
Sat Jan 31 19:27:17 PST 2004

tushar      04/01/31 20:27:17

  Modified:    BOOK/introduction introduction.ent
               BOOK/introduction/important important.xml
               BOOK/introduction/welcome credits.xml
  Added:       BOOK/introduction/important pkgmgt.xml
  Added package management section
  Revision  Changes    Path
  1.3       +1 -0      BLFS/BOOK/introduction/introduction.ent
  Index: introduction.ent
  RCS file: /home/cvsroot/BLFS/BOOK/introduction/introduction.ent,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -u -r1.2 -r1.3
  --- introduction.ent	4 Oct 2003 23:18:07 -0000	1.2
  +++ introduction.ent	1 Feb 2004 03:27:17 -0000	1.3
  @@ -13,6 +13,7 @@
   <!ENTITY intro-welcome-askhelp SYSTEM "welcome/askhelp.xml">
   <!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">
   <!ENTITY intro-important-bootscripts SYSTEM "important/bootscripts.xml">
  1.4       +1 -0      BLFS/BOOK/introduction/important/important.xml
  Index: important.xml
  RCS file: /home/cvsroot/BLFS/BOOK/introduction/important/important.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -u -r1.3 -r1.4
  --- important.xml	4 Oct 2003 23:18:07 -0000	1.3
  +++ important.xml	1 Feb 2004 03:27:17 -0000	1.4
  @@ -2,6 +2,7 @@
   <?dbhtml filename="important.html" dir="introduction"?>
   <title>Important Information</title>
  1.1                  BLFS/BOOK/introduction/important/pkgmgt.xml
  Index: pkgmgt.xml
  <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>
  <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>
  <para>There are some hints written on the topic of package management. Visit
  the <ulink url="">Hints subproject</ulink>
  to find if one of them fits your need.</para>
  <title>Upgrade Issues</title>
  <para>Following are some points that you should be aware of when upgrading
  pacakges, especially on a running system.</para>
  <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></filename>. Say you upgrade the package to a newer version
  foo-1.2.4 that installs a shared library with soname <filename></filename>.
  In this case, all packages that are dynamically linked to <filename></filename>
  need to be recompiled to link against <filename></filename>. Note that
  you should not remove the previous libraries till the dependent packages are
  <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>
  <title>Package Management Techniques</title>
  <para>The following are some common package management techniques.</para>
  <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>
  <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>
  <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 &&
  make &&
  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/</filename>
  instead of <filename>/usr/lib/</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 &&
  make &&
  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
  <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>
  <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>
  <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>
  <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="">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
  1.161     +3 -0      BLFS/BOOK/introduction/welcome/credits.xml
  Index: credits.xml
  RCS file: /home/cvsroot/BLFS/BOOK/introduction/welcome/credits.xml,v
  retrieving revision 1.160
  retrieving revision 1.161
  diff -u -u -r1.160 -r1.161
  --- credits.xml	25 Jan 2004 19:17:08 -0000	1.160
  +++ credits.xml	1 Feb 2004 03:27:17 -0000	1.161
  @@ -39,6 +39,9 @@
   <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>
   <listitem><para>Chapter 03: /etc/inputrc: <emphasis>Chris Lynn</emphasis>.

More information about the blfs-book mailing list