Context Navigation

-              rfb31251
+              r20828163
 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
+And before you begin to wonder, NO&mdash;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
 …
 <itemizedlist>
 <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>
+the goals of these books&mdash;teaching how a Linux system is built.</para></listitem>
 <listitem><para>There are multiple solutions for package management, each having
 its strengths and drawbacks. Including one that satifies all audiences is
 …
 <title>Upgrade Issues</title>
 <para>A Package Manager makes it easy to upgrade to newer versions as and when they
+<para>A Package Manager makes it easy to upgrade to newer versions when they
 are released. Generally the instructions in the <acronym>LFS</acronym> and
 <acronym>BLFS</acronym> Book can be used to upgrade to the newer versions.
 Following are some points that you should be aware of when upgrading
+Here are some points that you should be aware of when upgrading
 packages, especially on a running system.</para>
 <itemizedlist>
 <listitem><para>It is recommended that if one of the toolchain package (glibc, gcc,
+<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
 <acronym>LFS</acronym>. Though you <emphasis>may</emphasis> be able to get 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
+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></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
+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 soname of the library.) For
 example, consider a package foo-1.2.3 that installs a shared library with soname
+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 soname <filename>libfoo.so.2</filename>.
+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
 …
 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>
+package management because they plan on rebuilding the entire system
 when a package is changed.</para>
 …
 instructions may not install the package properly:</para>
 <screen><userinput><command>./configure --prefix=/usr/pkg/libfoo/1.1 &amp;&amp;
 make &amp;&amp;
+<screen><userinput><command>./configure --prefix=/usr/pkg/libfoo/1.1
+make
 make install</command></userinput></screen>
 …
 This approach works as follows:</para>
 <screen><userinput><command>./configure --prefix=/usr &amp;&amp;
 make &amp;&amp;
+<screen><userinput><command>./configure --prefix=/usr
+make
 make DESTDIR=/usr/pkg/libfoo/1.1 install</command></userinput></screen>
 …
 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; hence
+library may cause some unwanted side-effects during installation. Therefore,
 do perform some tests to ensure that the package manager does not break
 anything and logs all the appropriate files.</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>
+commercial distributions. Examples of package managers that follow this
+approach are RPM, pkg-utils, Debian's apt, and Gentoo's Portage system.</para>
 </sect3>

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

Context Navigation

Changeset 20828163 for introduction/important/pkgmgt.xml

Legend:

introduction/important/pkgmgt.xml

Download in other formats: