From 2082816350c05d8e803da634f663226824fb8b98 Mon Sep 17 00:00:00 2001 From: Bruce Dubbs Date: Fri, 4 Feb 2005 07:30:54 +0000 Subject: [PATCH] Minor wording changes in chapters 1 and 2 git-svn-id: svn://svn.linuxfromscratch.org/BLFS/trunk/BOOK@3390 af4574ff-66df-0310-9fd7-8a98e5e911e0 --- general.ent | 4 +-- introduction/important/beyond.xml | 4 +-- introduction/important/patches.xml | 2 +- introduction/important/pkgmgt.xml | 38 ++++++++++++++-------------- introduction/important/position.xml | 6 ++--- introduction/important/unpacking.xml | 16 ++++++------ introduction/welcome/askhelp.xml | 2 +- introduction/welcome/conventions.xml | 10 ++++---- introduction/welcome/which.xml | 16 ++++++------ postlfs/config/autofs.xml | 2 +- 10 files changed, 50 insertions(+), 50 deletions(-) diff --git a/general.ent b/general.ent index 5ddef01eda..da30d87b30 100644 --- a/general.ent +++ b/general.ent @@ -1,8 +1,8 @@ - + - + diff --git a/introduction/important/beyond.xml b/introduction/important/beyond.xml index fb58994ea9..a1582963dc 100644 --- a/introduction/important/beyond.xml +++ b/introduction/important/beyond.xml @@ -84,8 +84,8 @@ executable in the Debian repository at Many of the newer packages follow the ./configure -&& make && make install dance -routine. Help on the options accepted by configure can be obtained via the +&& make && make install process. +Help on the options accepted by configure can be obtained via the command ./configure --help. Most of the packages contain documentation on compiling and diff --git a/introduction/important/patches.xml b/introduction/important/patches.xml index 7daab25671..4683a01ae9 100644 --- a/introduction/important/patches.xml +++ b/introduction/important/patches.xml @@ -14,7 +14,7 @@ Optional Patches 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: diff --git a/introduction/important/pkgmgt.xml b/introduction/important/pkgmgt.xml index d3fe8572ca..cb48c21538 100644 --- a/introduction/important/pkgmgt.xml +++ b/introduction/important/pkgmgt.xml @@ -16,7 +16,7 @@ Package Management is an often requested addition to the LFS 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—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 BLFS: Dealing with package management takes the focus away from -the goals of these books - Teaching how a Linux System is built. +the goals of these books—teaching how a Linux system is built. There are multiple solutions for package management, each having its strengths and drawbacks. Including one that satifies all audiences is difficult. @@ -42,28 +42,28 @@ to find if one of them fits your need. Upgrade Issues -A Package Manager makes it easy to upgrade to newer versions as and when they +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 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. -It is recommended that if one of the toolchain package (glibc, gcc, +If one of the toolchain package (glibc, gcc, binutils) needs to be upgraded to a newer minor vesion, it is safer to rebuild LFS. Though you may 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. 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 libfoo.so.1. Say you upgrade the package to a newer version -foo-1.2.4 that installs a shared library with soname libfoo.so.2. +foo-1.2.4 that installs a shared library with name libfoo.so.2. In this case, all packages that are dynamically linked to libfoo.so.1 need to be recompiled to link against libfoo.so.2. 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. 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 LFS +package management because they plan on rebuilding the entire system when a package is changed. @@ -129,8 +129,8 @@ installed in /usr 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: -./configure --prefix=/usr/pkg/libfoo/1.1 && -make && +./configure --prefix=/usr/pkg/libfoo/1.1 +make make install The installation will work, but the dependent packages may not link to @@ -140,8 +140,8 @@ instead of /usr/lib/libfoo.so.1 as you would expect. The co approach is to use DESTDIR strategy to fake installation of the package. This approach works as follows: -./configure --prefix=/usr && -make && +./configure --prefix=/usr +make make DESTDIR=/usr/pkg/libfoo/1.1 install 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 cp, install, mv 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. @@ -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. 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. +commercial distributions. Examples of package managers that follow this +approach are RPM, pkg-utils, Debian's apt, and Gentoo's Portage system. diff --git a/introduction/important/position.xml b/introduction/important/position.xml index 93cf2a0fa1..fd75acae89 100644 --- a/introduction/important/position.xml +++ b/introduction/important/position.xml @@ -21,9 +21,9 @@ In traditional Unix systems, /usr usually contains files that come with the system distribution, and the -/usr/local 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 /usr/local, except perhaps for creating the basic +/usr/local tree is free for the local administrator to manage. +The only really hard and fast rule is that Unix distributions should not +touch /usr/local, except perhaps to create the basic directories within it. With Linux distributions, like Red Hat, Debian etc. a possible rule is diff --git a/introduction/important/unpacking.xml b/introduction/important/unpacking.xml index 9ca08d1d01..07dcb26ab5 100644 --- a/introduction/important/unpacking.xml +++ b/introduction/important/unpacking.xml @@ -11,9 +11,9 @@ $Date$ -Notes on downloading, unpacking and compiling software +Notes on building software -Those people who have built a LFS system will be aware +Those people who have built an LFS 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. @@ -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. -While you can keep the source TAR balls anywhere you like, we +While you can keep the source files anywhere you like, we assume that you have unpacked them and unzipped any required patches into /usr/src. @@ -38,7 +38,7 @@ code, but if in doubt, start from a clean tree. Unpacking the software If a file is tar'ed and gzip'ed, it is unpacked by running one of -the following two commands, depending on the filename: +the following commands, depending on the filename: tar -xvzf filename.tar.gz tar -xvzf filename.tgz @@ -53,10 +53,10 @@ running: bzcat filename.tar.bz2 | tar -xv -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 -/usr/src and then to run one of the following -commands depending on whether the file is .gz or .bz2: +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 +/usr/src and then to run one of the following commands +depending on whether the file is .gz or .bz2: gunzip patchname.gz bunzip2 patchname.bz2 diff --git a/introduction/welcome/askhelp.xml b/introduction/welcome/askhelp.xml index 606c95f7e8..2424f78e3b 100644 --- a/introduction/welcome/askhelp.xml +++ b/introduction/welcome/askhelp.xml @@ -74,7 +74,7 @@ receiving, that we won't help you. It'll just help us to see other possible causes of your problem.) 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 diff --git a/introduction/welcome/conventions.xml b/introduction/welcome/conventions.xml index e46eb9123f..526c304312 100644 --- a/introduction/welcome/conventions.xml +++ b/introduction/welcome/conventions.xml @@ -20,15 +20,15 @@ throughout the book. Following are some examples:
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.
+in the explanation sections to identify references to specific commands. + install-info: unknown option `--dir-file=/mnt/lfs/usr/info/dir'
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 /etc/lilo.conf
+show filenames such as /boot/grub/grub.conf Emphasis @@ -56,7 +56,7 @@ Therefore, this whole section is generally typed as seen. [REPLACED TEXT] -
This form of text is used to encapsulate text that is -not to be typed as seen or copy and pasted.
+
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.
diff --git a/introduction/welcome/which.xml b/introduction/welcome/which.xml index 8904a24ea5..74447ec0dd 100644 --- a/introduction/welcome/which.xml +++ b/introduction/welcome/which.xml @@ -13,17 +13,17 @@ Which sections of the book do I want? -Unlike the Linux From Scratch book, BLFS isn't +Unlike the Linux From Scratch book, BLFS isn't designed to be followed in a linear manner. This is because LFS - 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. BLFS is where we try to guide you through going -from the base system to your intended destination and so choice is very much -involved. + 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. BLFS 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. Everyone who reads the book will want to read certain sections. The - part - which you are currently -reading - contains generic information. Especially take note of the + part–which you are currently +reading–contains generic information. Especially take note of the information in Important Information (), as this contains comments about how to unpack software and various other aspects which apply throughout the book. diff --git a/postlfs/config/autofs.xml b/postlfs/config/autofs.xml index 1cff11677a..890315076c 100644 --- a/postlfs/config/autofs.xml +++ b/postlfs/config/autofs.xml @@ -18,7 +18,7 @@ $Date$ -Automate Mounting of Removable File Systems +Automate Mounting of File Systems Autofs