chapter06/pkgmgt.xml

   1 <?xml version="1.0" encoding="ISO-8859-1"?>
   2 <!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
   3   "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
   4   <!ENTITY % general-entities SYSTEM "../general.ent">
   5   %general-entities;
   6 ]>
   7
   8 <sect1 id="ch-system-pkgmgt">
   9   <?dbhtml filename="pkgmgt.html"?>
  10
  11   <title>Package Management</title>
  12
  13   <para>Package Management is an often requested addition to the LFS Book. A
  14   Package Manager allows tracking the installation of files making it easy to
  15   remove and upgrade packages. As well as the binary and library files, a
  16   package manager will handle the installation of configuration files.  Before
  17   you begin to wonder, NO&mdash;this section will not talk about nor recommend
  18   any particular package manager. What it provides is a roundup of the more
  19   popular techniques and how they work. The perfect package manager for you may
  20   be among these techniques or may be a combination of two or more of these
  21   techniques. This section briefly mentions issues that may arise when upgrading
  22   packages.</para>
  23
  24   <para>Some reasons why no package manager is mentioned in LFS or BLFS
  25   include:</para>
  26
  27   <itemizedlist>
  28     <listitem>
  29       <para>Dealing with package management takes the focus away from the goals
  30       of these books&mdash;teaching how a Linux system is built.</para>
  31     </listitem>
  32
  33     <listitem>
  34       <para>There are multiple solutions for package management, each having
  35       its strengths and drawbacks.  Including one that satisfies all audiences
  36       is difficult.</para>
  37     </listitem>
  38   </itemizedlist>
  39
  40   <para>There are some hints written on the topic of package management. Visit
  41   the <ulink url="&hints-index;">Hints Project</ulink> and see if one of them
  42   fits your need.</para>
  43
  44   <sect2>
  45     <title>Upgrade Issues</title>
  46
  47     <para>A Package Manager makes it easy to upgrade to newer versions when they
  48     are released. Generally the instructions in the LFS and BLFS Book can be
  49     used to upgrade to the newer versions. Here are some points that you should
  50     be aware of when upgrading packages, especially on a running system.</para>
  51
  52     <itemizedlist>
  53       <listitem>
  54         <para>If Glibc needs to be upgraded to a newer version, (e.g.  from
  55         glibc-2.19 to glibc-2.20), it is safer to rebuild LFS.  Though you
  56         <emphasis>may</emphasis> be able to rebuild all the packages in their
  57         dependency order, we do not recommend it.  </para>
  58       </listitem>
  59
  60       <listitem>
  61         <para>If a package containing a shared library is updated, and if the
  62         name of the library changes, then all the packages dynamically linked
  63         to the library need to be recompiled to link against the newer library.
  64         (Note that there is no correlation between the package version and the
  65         name of the library.) For example, consider a package foo-1.2.3 that
  66         installs a shared library with name
  67         <filename class='libraryfile'>libfoo.so.1</filename>. Say you upgrade
  68         the package to a newer version foo-1.2.4 that installs a shared library
  69         with name <filename class='libraryfile'>libfoo.so.2</filename>. In this
  70         case, all packages that are dynamically linked to
  71         <filename class='libraryfile'>libfoo.so.1</filename> need to be
  72         recompiled to link against
  73         <filename class='libraryfile'>libfoo.so.2</filename>. Note that you
  74         should not remove the previous libraries until the dependent packages
  75         are recompiled.</para>
  76       </listitem>
  77     </itemizedlist>
  78
  79   </sect2>
  80
  81   <sect2>
  82     <title>Package Management Techniques</title>
  83
  84     <para>The following are some common package management techniques. Before
  85     making a decision on a package manager, do some research on the various
  86     techniques, particularly the drawbacks of the particular scheme.</para>
  87
  88     <sect3>
  89       <title>It is All in My Head!</title>
  90
  91       <para>Yes, this is a package management technique. Some folks do not find
  92       the need for a package manager because they know the packages intimately
  93       and know what files are installed by each package. Some users also do not
  94       need any package management because they plan on rebuilding the entire
  95       system when a package is changed.</para>
  96
  97     </sect3>
  98
  99     <sect3>
 100       <title>Install in Separate Directories</title>
 101
 102       <para>This is a simplistic package management that does not need any extra
 103       package to manage the installations. Each package is installed in a
 104       separate directory. For example, package foo-1.1 is installed in
 105       <filename class='directory'>/usr/pkg/foo-1.1</filename>
 106       and a symlink is made from <filename>/usr/pkg/foo</filename> to
 107       <filename class='directory'>/usr/pkg/foo-1.1</filename>. When installing
 108       a new version foo-1.2, it is installed in
 109       <filename class='directory'>/usr/pkg/foo-1.2</filename> and the previous
 110       symlink is replaced by a symlink to the new version.</para>
 111
 112       <para>Environment variables such as <envar>PATH</envar>,
 113       <envar>LD_LIBRARY_PATH</envar>, <envar>MANPATH</envar>,
 114       <envar>INFOPATH</envar> and <envar>CPPFLAGS</envar> need to be expanded to
 115       include <filename>/usr/pkg/foo</filename>. For more than a few packages,
 116       this scheme becomes unmanageable.</para>
 117
 118     </sect3>
 119
 120     <sect3>
 121       <title>Symlink Style Package Management</title>
 122
 123       <para>This is a variation of the previous package management technique.
 124       Each package is installed similar to the previous scheme. But instead of
 125       making the symlink, each file is symlinked into the
 126       <filename class='directory'>/usr</filename> hierarchy. This removes the
 127       need to expand the environment variables. Though the symlinks can be
 128       created by the user to automate the creation, many package managers have
 129       been written using this approach. A few of the popular ones include Stow,
 130       Epkg, Graft, and Depot.</para>
 131
 132       <para>The installation needs to be faked, so that the package thinks that
 133       it is installed in <filename class="directory">/usr</filename> though in
 134       reality it is installed in the
 135       <filename class="directory">/usr/pkg</filename> hierarchy. Installing in
 136       this manner is not usually a trivial task. For example, consider that you
 137       are installing a package libfoo-1.1. The following instructions may
 138       not install the package properly:</para>
 139
 140 <screen role="nodump"><userinput>./configure --prefix=/usr/pkg/libfoo/1.1
 141 make
 142 make install</userinput></screen>
 143
 144       <para>The installation will work, but the dependent packages may not link
 145       to libfoo as you would expect. If you compile a package that links against
 146       libfoo, you may notice that it is linked to
 147       <filename class='libraryfile'>/usr/pkg/libfoo/1.1/lib/libfoo.so.1</filename>
 148       instead of <filename class='libraryfile'>/usr/lib/libfoo.so.1</filename>
 149       as you would expect. The correct approach is to use the
 150       <envar>DESTDIR</envar> strategy to fake installation of the package. This
 151       approach works as follows:</para>
 152
 153 <screen role="nodump"><userinput>./configure --prefix=/usr
 154 make
 155 make DESTDIR=/usr/pkg/libfoo/1.1 install</userinput></screen>
 156
 157       <para>Most packages support this approach, but there are some which do not.
 158       For the non-compliant packages, you may either need to manually install the
 159       package, or you may find that it is easier to install some problematic
 160       packages into <filename class='directory'>/opt</filename>.</para>
 161
 162     </sect3>
 163
 164     <sect3>
 165       <title>Timestamp Based</title>
 166
 167       <para>In this technique, a file is timestamped before the installation of
 168       the package. After the installation, a simple use of the
 169       <command>find</command> command with the appropriate options can generate
 170       a log of all the files installed after the timestamp file was created. A
 171       package manager written with this approach is install-log.</para>
 172
 173       <para>Though this scheme has the advantage of being simple, it has two
 174       drawbacks. If, during installation, the files are installed with any
 175       timestamp other than the current time, those files will not be tracked by
 176       the package manager. Also, this scheme can only be used when one package
 177       is installed at a time. The logs are not reliable if two packages are
 178       being installed on two different consoles.</para>
 179
 180     </sect3>
 181
 182     <sect3>
 183       <title>Tracing Installation Scripts</title>
 184
 185       <para>In this approach, the commands that the installation scripts perform
 186       are recorded.  There are two techniques that one can use:</para>
 187
 188       <para>The <envar>LD_PRELOAD</envar> environment variable can be set to
 189       point to a library to be preloaded before installation.  During
 190       installation, this library tracks the packages that are being installed by
 191       attaching itself to various executables such as <command>cp</command>,
 192       <command>install</command>, <command>mv</command> and tracking the system
 193       calls that modify the filesystem. For this approach to work, all the
 194       executables need to be dynamically linked without the suid or sgid bit.
 195       Preloading the library may cause some unwanted side-effects during
 196       installation. Therefore, it is advised that one performs some tests to
 197       ensure that the package manager does not break anything and logs all the
 198       appropriate files.</para>
 199
 200       <para>The second technique is to use <command>strace</command>, which
 201       logs all system calls made during the execution of the installation
 202       scripts.</para>
 203     </sect3>
 204
 205     <sect3>
 206       <title>Creating Package Archives</title>
 207
 208       <para>In this scheme, the package installation is faked into a separate
 209       tree as described in the Symlink style package management. After the
 210       installation, a package archive is created using the installed files.
 211       This archive is then used to install the package either on the local
 212       machine or can even be used to install the package on other machines.</para>
 213
 214       <para>This approach is used by most of the package managers found in the
 215       commercial distributions. Examples of package managers that follow this
 216       approach are RPM (which, incidentally, is required by the <ulink
 217       url="http://refspecs.linuxfoundation.org/lsb.shtml">Linux
 218       Standard Base Specification</ulink>), pkg-utils, Debian's apt, and
 219       Gentoo's Portage system.  A hint describing how to adopt this style of
 220       package management for LFS systems is located at <ulink
 221       url="&hints-root;fakeroot.txt"/>.</para>
 222
 223       <para>Creation of package files that include dependency information is
 224       complex and is beyond the scope of LFS.</para>
 225
 226       <para>Slackware uses a <command>tar</command> based system for package
 227       archives.  This system purposely does not handle package dependencies
 228       as more complex package managers do.  For details of Slackware package
 229       management, see <ulink
 230       url="http://www.slackbook.org/html/package-management.html"/>.</para>
 231     </sect3>
 232
 233     <sect3>
 234       <title>User Based Management</title>
 235
 236       <para>This scheme, unique to LFS, was devised by Matthias Benkmann, and is
 237       available from the <ulink url="&hints-index;">Hints Project</ulink>. In
 238       this scheme, each package is installed as a separate user into the
 239       standard locations. Files belonging to a package are easily identified by
 240       checking the user ID. The features and shortcomings of this approach are
 241       too complex to describe in this section. For the details please see the
 242       hint at <ulink url="&hints-root;more_control_and_pkg_man.txt"/>.</para>
 243
 244     </sect3>
 245
 246   </sect2>
 247
 248   <sect2>
 249     <title>Deploying LFS on Multiple Systems</title>
 250
 251     <para>One of the advantages of an LFS system is that there are no files that
 252     depend on the position of files on a disk system.  Cloning an LFS build to
 253     another computer with the same architecture as the base system is as
 254     simple as using <command>tar</command> on the LFS partition that contains
 255     the root directory (about 250MB uncompressed for a base LFS build), copying
 256     that file via network transfer or CD-ROM to the new system and expanding
 257     it.  From that point, a few configuration files will have to be changed.
 258     Configuration files that may need to be updated include:
 259     <filename>/etc/hosts</filename>,
 260     <filename>/etc/fstab</filename>,
 261     <filename>/etc/passwd</filename>,
 262     <filename>/etc/group</filename>,
 263     <phrase revision="systemd">
 264       <filename>/etc/shadow</filename>, and
 265       <filename>/etc/ld.so.conf</filename>.
 266     </phrase>
 267     <phrase revision="sysv">
 268       <filename>/etc/shadow</filename>,
 269       <filename>/etc/ld.so.conf</filename>,
 270       <filename>/etc/sysconfig/rc.site</filename>,
 271       <filename>/etc/sysconfig/network</filename>, and
 272       <filename>/etc/sysconfig/ifconfig.eth0</filename>.
 273     </phrase>
 274     </para>
 275
 276     <para>A custom kernel may need to be built for the new system depending on
 277     differences in system hardware and the original kernel
 278     configuration.</para>
 279
 280     <note><para>There have been some reports of issues when copying between
 281     similar but not identical architectures. For instance, the instruction set
 282     for an Intel system is not identical with an AMD processor and later
 283     versions of some processors may have instructions that are unavailable in
 284     earlier versions.</para></note>
 285
 286     <para>Finally the new system has to be made bootable via <xref
 287     linkend="ch-bootable-grub"/>.</para>
 288
 289   </sect2>
 290
 291 </sect1>