Context Navigation

-              r8aefeb67
+              r4382a36
     <itemizedlist>
       <listitem>
+        <para>If one of the toolchain package (glibc, gcc,
+        binutils) needs to be upgraded to a newer minor vesion, it is safer to rebuild
+        LFS. Though you <emphasis>may</emphasis> 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.1 to glibc-2.3.2 will not
+        usually cause any problems.</para>
+        <para>If one of the toolchain packages
+        (<application>Glibc</application>, <application>GCC</application> or
+        <application>Binutils</application>) needs to be upgraded to a newer
+        minor vesion, it is safer to rebuild LFS. Though you
+        <emphasis>may</emphasis> 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.</para>
       </listitem>
       <listitem>
         <para>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 corelation 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
+        <filename>libfoo.so.1</filename>. Say you upgrade the package to a newer version
+        foo-1.2.4 that installs a shared library with name <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>
+        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
+        <filename class='libraryfile'>libfoo.so.1</filename>. Say you upgrade
+        the package to a newer version foo-1.2.4 that installs a shared library
+        with name <filename class='libraryfile'>libfoo.so.2</filename>. In this
+        case, all packages that are dynamically linked to
+        <filename class='libraryfile'>libfoo.so.1</filename> need to be
+        recompiled to link against
+        <filename class='libraryfile'>libfoo.so.2</filename>. Note that you
+        should not remove the previous libraries until the dependent packages
+        are recompiled.</para>
       </listitem>
       <listitem>
 …
     <para>The following are some common package management techniques. Before
     making a decision on a package manager, do a research on the various
+    making a decision on a package manager, do some research on the various
     techniques, particularly the drawbacks of the particular scheme.</para>
 …
       <para>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 <filename>/usr/pkg/foo-1.1</filename>
+      For example, package foo-1.1 is installed in
+      <filename class='directory'>/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="intro-important-beyond"/> need to be expanded to
+      <filename class='directory'>/usr/pkg/foo-1.1</filename>. When installing
+      a new version foo-1.2, it is installed in
+      <filename class='directory'>/usr/pkg/foo-1.2</filename> and the previous
+      symlink is replaced by a symlink to the new version.</para>
+      <para>The environment variables such as those mentioned in
+      <xref linkend="intro-important-beyond"/> need to be expanded to
       include <filename>/usr/pkg/foo</filename>. For more than a few packages,
       this scheme becomes unmanageable.</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.
+      A few of the popular ones are Stow, Epkg, Graft, and Depot.</para>
+      <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 the
+      <filename class='directory'>/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 using this approach. A 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 class="directory">/usr</filename> though in reality it is
       installed in <filename class="directory">/usr/pkg</filename> hierarchy.
+      installed in the <filename class="directory">/usr/pkg</filename> 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
 …
 make install</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>
+      <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 class='libraryfile'>/usr/pkg/libfoo/1.1/lib/libfoo.so.1</filename>
+      instead of <filename class='libraryfile'>/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>./configure --prefix=/usr
 …
 make DESTDIR=/usr/pkg/libfoo/1.1 install</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>
+      <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 class='directory'>/opt</filename>.</para>
     </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>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.
 …
       <title>User Based Management</title>
       <para>This scheme, that is unique to LFS, was devised by Matthias Benkmann,
+      <para>This scheme, unique to LFS, 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 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
+      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>

Note: See TracChangeset for help on using the changeset viewer.

Context Navigation

Changeset 4382a36 for introduction/important

Legend:

introduction/important/pkgmgt.xml

Download in other formats: