Changeset 6a156bab for chapter08/pkgmgt.xml

Timestamp:

06/12/2020 04:40:07 AM (4 years ago)

Author:

Bruce Dubbs <bdubbs@…>

Branches:

10.0, 10.0-rc1, 10.1, 10.1-rc1, 11.0, 11.0-rc1, 11.0-rc2, 11.0-rc3, 11.1, 11.1-rc1, 11.2, 11.2-rc1, 11.3, 11.3-rc1, 12.0, 12.0-rc1, 12.1, 12.1-rc1, arm, bdubbs/gcc13, ml-11.0, multilib, renodr/libudev-from-systemd, s6-init, trunk, xry111/arm64, xry111/arm64-12.0, xry111/clfs-ng, xry111/lfs-next, xry111/loongarch, xry111/loongarch-12.0, xry111/loongarch-12.1, xry111/mips64el, xry111/pip3, xry111/rust-wip-20221008, xry111/update-glibc

Children:

26fec27

Parents:

ea7ec72

Message:

Mostly text updates in Chapter 8.
There are a couple of minor command changes.

git-svn-id: ​http://svn.linuxfromscratch.org/LFS/branches/cross2@11924 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689

File:

• chapter08/pkgmgt.xml (modified) (2 diffs)

chapter08/pkgmgt.xml

@@ -46 +46 @@
 
     <para>A Package Manager makes it easy to upgrade to newer versions when they
-    are released. Generally the instructions in the LFS and BLFS Book can be
+    are released. Generally the instructions in the LFS and BLFS books can be
     used to upgrade to the newer versions. Here are some points that you should
     be aware of when upgrading packages, especially on a running system.</para>
@@ -53 +53 @@
       <listitem>
         <para>If Glibc needs to be upgraded to a newer version, (e.g.  from
-        glibc-2.19 to glibc-2.20), it is safer to rebuild LFS.  Though you
+        glibc-2.31 to glibc-2.32), it is safer to rebuild LFS.  Though you
         <emphasis>may</emphasis> be able to rebuild all the packages in their
         dependency order, we do not recommend it.  </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 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>
-    </itemizedlist>
+      <listitem> <para>If a package containing a shared library is updated, and
+      if the name of the library changes, then any the packages dynamically
+      linked to the library need to be recompiled in order 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>. If 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, any
+      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> in order to
+      use the new library version. You should not remove the previous
+      libraries unless all the dependent packages are recompiled.</para>
+      </listitem> </itemizedlist>
 
   </sect2>