Changeset 20828163

Timestamp:

02/04/2005 07:30:54 AM (19 years ago)

Author:

Bruce Dubbs <bdubbs@…>

Branches:

10.0, 10.1, 11.0, 11.1, 11.2, 11.3, 12.0, 12.1, 6.0, 6.1, 6.2, 6.2.0, 6.2.0-rc1, 6.2.0-rc2, 6.3, 6.3-rc1, 6.3-rc2, 6.3-rc3, 7.10, 7.4, 7.5, 7.6, 7.6-blfs, 7.6-systemd, 7.7, 7.8, 7.9, 8.0, 8.1, 8.2, 8.3, 8.4, 9.0, 9.1, basic, bdubbs/svn, elogind, gnome, kde5-13430, kde5-14269, kde5-14686, kea, ken/TL2024, ken/inkscape-core-mods, ken/tuningfonts, krejzi/svn, lazarus, lxqt, nosym, perl-modules, plabs/newcss, plabs/python-mods, python3.11, qt5new, rahul/power-profiles-daemon, renodr/vulkan-addition, systemd-11177, systemd-13485, trunk, upgradedb, xry111/intltool, xry111/llvm18, xry111/soup3, xry111/test-20220226, xry111/xf86-video-removal

Children:

843cc38c

Parents:

fb31251

Message:

Minor wording changes in chapters 1 and 2

git-svn-id: svn://svn.linuxfromscratch.org/BLFS/trunk/BOOK@3390 af4574ff-66df-0310-9fd7-8a98e5e911e0

Files:

• general.ent (modified) (1 diff)
• introduction/important/beyond.xml (modified) (1 diff)
• introduction/important/patches.xml (modified) (1 diff)
• introduction/important/pkgmgt.xml (modified) (8 diffs)
• introduction/important/position.xml (modified) (1 diff)
• introduction/important/unpacking.xml (modified) (4 diffs)
• introduction/welcome/askhelp.xml (modified) (1 diff)
• introduction/welcome/conventions.xml (modified) (3 diffs)
• introduction/welcome/which.xml (modified) (1 diff)
• postlfs/config/autofs.xml (modified) (1 diff)

general.ent

@@ -1 @@
-<!ENTITY day          "03">
+<!ENTITY day          "04">
 <!ENTITY month        "02">
 <!ENTITY year         "2005">
 <!ENTITY version      "svn-&year;&month;&day;">
-<!ENTITY releasedate  "February &day;rd, &year;">
+<!ENTITY releasedate  "February &day;th, &year;">
 <!ENTITY pubdate      "&year;-&month;-&day;"> <!-- metadata req. by TLDP -->
 <!ENTITY blfs-version "cvs">                  <!-- cvs|[release #] -->

introduction/important/beyond.xml

@@ -85 +85 @@
 
 <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

@@ -15 +15 @@
 
 <para>As you follow the various sections in the book, you will observe that
-the book includes various patches that are required for a successful and
+the book occasionally includes patches that are required for a successful and
 secure installation of the packages. The general policy of the book is to
 include patches that fall in one of the following criteria:</para>

introduction/important/pkgmgt.xml

@@ -17 +17 @@
 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
@@ -29 +29 @@
 <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
@@ -43 +43 @@
 <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
@@ -91 +91 @@
 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>
 
@@ -130 +130 @@
 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>
 
@@ -141 +141 @@
 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>
 
@@ -177 +177 @@
 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>
@@ -193 +193 @@
 
 <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

@@ -22 +22 @@
 <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

@@ -12 +12 @@
 </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
@@ -24 +24 @@
 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>
@@ -39 +39 @@
 
 <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
@@ -54 +54 @@
 <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

@@ -75 +75 @@
 
 <para>Expect guidance instead of specific instructions. If you are
-instructed to read something, please do so, it generally implies that
+instructed to read something, please do so. It generally implies that
 the answer was way too obvious and that the question would not have been asked 
 if a little research was done prior to asking. The volunteers in the mailing 

introduction/welcome/conventions.xml

@@ -21 +21 @@
 <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 
@@ -29 +29 @@
 <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>
@@ -57 +57 @@
 <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

@@ -14 +14 @@
 <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 

postlfs/config/autofs.xml

@@ -19 +19 @@
 </sect1info>
 <?dbhtml filename="autofs.html"?>
-<title>Automate Mounting of Removable File Systems</title>
+<title>Automate Mounting of File Systems</title>
 <indexterm zone="autofs">
 <primary sortas="a-Autofs">Autofs</primary></indexterm>