linux-from-scratch/glfs
1
0
Fork 0
mirror of https://github.com/Zeckmathederg/glfs.git synced 2025-01-23 22:42:14 +08:00
Code Issues Actions Packages Projects Releases Wiki Activity

Minor wording changes in chapters 1 and 2

Browse Source 
git-svn-id: svn://svn.linuxfromscratch.org/BLFS/trunk/BOOK@3390 af4574ff-66df-0310-9fd7-8a98e5e911e0
This commit is contained in:
Bruce Dubbs 2005-02-04 07:30:54 +00:00
parent fb31251d18
commit 2082816350
10 changed files with 50 additions and 50 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
general.ent
View File

@ -1,8 +1,8 @@
<!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 #] -->
<!ENTITY lfs-version "stable"> <!-- stable|testing|unstable] -->

4
introduction/important/beyond.xml
View File

@ -84,8 +84,8 @@ executable in the Debian repository at
<itemizedlist>
<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>
<listitem><para>Most of the packages contain documentation on compiling and

2
introduction/important/patches.xml
View File

@ -14,7 +14,7 @@
<title>Optional Patches</title>
<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>

38
introduction/important/pkgmgt.xml
View File

@ -16,7 +16,7 @@
<para>Package Management is an often requested addition
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
package manager for you may be among these techniques or may be a combination
@ -28,7 +28,7 @@ or <acronym>BLFS</acronym>:</para>
<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
difficult.</para></listitem>
@ -42,28 +42,28 @@ to find if one of them fits your need.</para>
<sect2>
<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
you should not remove the previous libraries till the dependent packages are
@ -90,7 +90,7 @@ techniques, particularly the drawbacks of the particular scheme.</para>
<para>Yes, this is a package management technique. Some folks do not find the
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>
</sect3>
@ -129,8 +129,8 @@ installed in <filename class="directory">/usr</filename> though in reality it is
task. For example, consider that you are installing a package libfoo-1.1. The following
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>
<para>The installation will work, but the dependent packages may not link to
@ -140,8 +140,8 @@ instead of <filename>/usr/lib/libfoo.so.1</filename> as you would expect. The co
approach is to use <envar>DESTDIR</envar> strategy to fake installation of the package.
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>
<para>Most of the packages do support this approach, but there are some which do not.
@ -176,7 +176,7 @@ attaching itself to various executables such as <command>cp</command>,
<command>install</command>, <command>mv</command> and tracking the system
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>
@ -192,8 +192,8 @@ This archive is then used to install the package either on the local
machine or can even be used to install the package on other machines.</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>

6
introduction/important/position.xml
View File

@ -21,9 +21,9 @@
<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>
<para>With Linux distributions, like Red Hat, Debian etc. a possible rule is

16
introduction/important/unpacking.xml
View File

@ -11,9 +11,9 @@
<date>$Date$</date>
</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
their own software.</para>
@ -23,7 +23,7 @@ from which you can download the package. We do however keep a selection of
patches available via http. These are referenced as needed in the
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>
@ -38,7 +38,7 @@ code, but if in doubt, start from a clean tree.</para>
<title>Unpacking the software</title>
<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
tar -xvzf filename.tgz
@ -53,10 +53,10 @@ running:</para>
<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
bunzip2 patchname.bz2</command></screen>

2
introduction/welcome/askhelp.xml
View File

@ -74,7 +74,7 @@ receiving,</para></listitem>
that we won't help you. It'll just help us to see other possible causes of your problem.)</para>
<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
list prefer not to be used as an alternative to doing reasonable research on

10
introduction/welcome/conventions.xml
View File

@ -20,15 +20,15 @@ throughout the book. Following are some examples:</para>
<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
`--dir-file=/mnt/lfs/usr/info/dir'</filename></para>
<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>
@ -56,7 +56,7 @@ Therefore, this whole section is generally typed as seen.</para></blockquote>
<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>

16
introduction/welcome/which.xml
View File

@ -13,17 +13,17 @@
<?dbhtml filename="which.html"?>
<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
which apply throughout the book.</para>

2
postlfs/config/autofs.xml
View File

@ -18,7 +18,7 @@
<date>$Date$</date>
</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>