r4754 - trunk/BOOK/introduction/important

randy at linuxfromscratch.org randy at linuxfromscratch.org
Thu Jul 21 15:27:24 PDT 2005


Author: randy
Date: 2005-07-21 16:27:23 -0600 (Thu, 21 Jul 2005)
New Revision: 4754

Modified:
   trunk/BOOK/introduction/important/pkgmgt.xml
Log:
Various tagging and typo fixes to the 'Package Management' section

Modified: trunk/BOOK/introduction/important/pkgmgt.xml
===================================================================
--- trunk/BOOK/introduction/important/pkgmgt.xml	2005-07-21 21:49:02 UTC (rev 4753)
+++ trunk/BOOK/introduction/important/pkgmgt.xml	2005-07-21 22:27:23 UTC (rev 4754)
@@ -54,27 +54,33 @@
 
     <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>If you are upgrading a running system, be on the lookout for packages
@@ -90,7 +96,7 @@
     <title>Package Management Techniques</title>
 
     <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>
 
     <sect3>
@@ -109,14 +115,16 @@
 
       <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>
+      <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
+      <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>
 
@@ -125,16 +133,18 @@
     <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.
-      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
       not install the package properly:</para>
@@ -143,31 +153,35 @@
 make
 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
 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>
 
     <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.
       If during installation, the files are installed with any timestamp other than the
@@ -210,11 +224,11 @@
     <sect3>
       <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>
 




More information about the blfs-book mailing list