Context Navigation

-              rfb31251
+              r20828163
 <listitem><para>Many of the newer packages follow the <command>./configure
 &amp;&amp; make &amp;&amp; make install</command> <emphasis>dance</emphasis>
 routine. Help on the options accepted by configure can be obtained via the
+&amp;&amp; make &amp;&amp; make install</command> process.
+Help on the options accepted by configure can be obtained via the
 command <command>./configure --help</command>.</para></listitem>

introduction/important/patches.xml

rfb31251	r20828163
15	15
16	16	<para>As you follow the various sections in the book, you will observe that
17		the book ~~includes variou~~s patches that are required for a successful and
	17	the book occasionally includes patches that are required for a successful and
18	18	secure installation of the packages. The general policy of the book is to
19	19	include patches that fall in one of the following criteria:</para>

introduction/important/pkgmgt.xml

-              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>

introduction/important/position.xml

-              rfb31251
+              r20828163
 <para>In traditional Unix systems, <filename>/usr</filename> usually
 contains files that come with the system distribution, and the <filename>
 /usr/local</filename> tree is free for the local administrator to add things
 to.  The only really hard and fast rule is that Unix distributions should not
 touch <filename>/usr/local</filename>, except perhaps for creating the basic
+/usr/local</filename> tree is free for the local administrator to manage.
+The only really hard and fast rule is that Unix distributions should not
+touch <filename>/usr/local</filename>, except perhaps to create the basic
 directories within it.</para>

introduction/important/unpacking.xml

-              rfb31251
+              r20828163
 </sect1info>
 <?dbhtml filename="unpacking.html"?>
 <title>Notes on downloading, unpacking and compiling software</title>
+<title>Notes on building software</title>
 <para>Those people who have built a <acronym>LFS</acronym> system will be aware
+<para>Those people who have built an <acronym>LFS</acronym> system will be aware
 of the general principles of downloading and unpacking software.  We will
 however repeat some of that information here for those new to building
 …
 installation instructions.</para>
 <para>While you can keep the source <acronym>TAR</acronym> balls anywhere you like, we
+<para>While you can keep the source files anywhere you like, we
 assume that you have unpacked them and unzipped any required patches
 into <filename>/usr/src</filename>.</para>
 …
 <para>If a file is tar'ed and gzip'ed, it is unpacked by running one of
 the following two commands, depending on the filename:</para>
+the following commands, depending on the filename:</para>
 <screen><command>tar -xvzf filename.tar.gz
 …
 <screen><command>bzcat filename.tar.bz2 | tar -xv</command></screen>
 <para>Finally, you need to be able to unpack patches which are generally
 not tar'ed.  The best way to do this is to copy the patch file to
 <filename>/usr/src</filename> and then to run one of the following
 commands depending on whether the file is .gz or .bz2:</para>
+<para>Finally, you sometimes need to be able to unpack patches which are
+generally not tar'ed.  The best way to do this is to copy the patch file to
+<filename>/usr/src</filename> and then to run one of the following commands
+depending on whether the file is .gz or .bz2:</para>
 <screen><command>gunzip patchname.gz

introduction/welcome/askhelp.xml

rfb31251	r20828163
75	75
76	76	<para>Expect guidance instead of specific instructions. If you are
77		instructed to read something, please do so~~, i~~t generally implies that
	77	instructed to read something, please do so. It generally implies that
78	78	the answer was way too obvious and that the question would not have been asked
79	79	if a little research was done prior to asking. The volunteers in the mailing

introduction/welcome/conventions.xml

-              rfb31251
+              r20828163
 <blockquote><para>This form of text is designed to be typed exactly
 as seen unless otherwise noted in the surrounding text.  It is also used
 in the explanation sections to identify which of the commands is being
 referred to.</para></blockquote>
+in the explanation sections to identify references to specific commands.</para>
+</blockquote>
 <para><filename>install-info: unknown option
 …
 <blockquote><para>This form of text (fixed width text) is showing screen
 output, probably as the result of commands issued and is also used to
 show filenames such as <filename>/etc/lilo.conf</filename></para></blockquote>
+show filenames such as <filename>/boot/grub/grub.conf</filename></para></blockquote>
 <para><emphasis>Emphasis</emphasis></para>
 …
 <para><replaceable>[REPLACED TEXT]</replaceable></para>
 <blockquote><para>This form of text is used to encapsulate text that is
 not to be typed as seen or copy and pasted.</para></blockquote>
+<blockquote><para>This form of text is used to encapsulate text that should be
+modified and is not to be typed as seen or copy and pasted.</para></blockquote>
 </sect1>

introduction/welcome/which.xml

-              rfb31251
+              r20828163
 <title>Which sections of the book do I want?</title>
 <para>Unlike the Linux From Scratch book, <acronym>BLFS</acronym> isn't
+<para>Unlike the Linux From Scratch book, <acronym>BLFS</acronym> isn't
 designed to be followed in a linear manner.  This is because <acronym>LFS
 </acronym> provides instructions on how to create a base system which is
 capable of turning into anything from a web server to a multimedia desktop
 system.  <acronym>BLFS</acronym> is where we try to guide you through going
+from the base system to your intended destination and so choice is very much
 involved.</para>
+</acronym> provides instructions on how to create a base system which is
+capable of turning into anything from a web server to a multimedia desktop
+system.  <acronym>BLFS</acronym> is where we try to guide you in the process of
+going from the base system to your intended destination. Choice is very
+much involved.</para>
 <para>Everyone who reads the book will want to read certain sections.  The
 <xref linkend="introduction"/> part - which you are currently
 reading - contains generic information.  Especially take note of the
+<xref linkend="introduction"/> part&ndash;which you are currently
+reading&ndash;contains generic information.  Especially take note of the
 information in Important Information (<xref linkend="intro-important"/>), as
 this contains comments about how to unpack software and various other aspects

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

Context Navigation

Changeset 20828163 for introduction

Legend:

Download in other formats: