Changeset 1e59f09 for final-system

Timestamp:

May 17, 2006, 1:20:04 PM (19 years ago)

Author:

Jim Gifford <clfs@…>

Children:

0d80be2

Parents:

ba8680e

Message:

r3564@server (orig r1629): chris | 2006-05-17 13:05:26 -0700
More text updates, mostly to change LFS references to CLFS

Location:

final-system

Files:

• common/introduction.xml (modified) (3 diffs)
• common/pkgmgt.xml (modified) (5 diffs)
• x86/linux-headers.xml (modified) (1 diff)

final-system/common/introduction.xml

@@ -12 +12 @@
 
   <para os="a">In this chapter, we enter the building site and start
-  constructing the LFS system in earnest. The installation of this
+  constructing the CLFS system in earnest. The installation of this
   software is straightforward. Although in many cases the installation
   instructions could be made shorter and more generic, we have opted
@@ -35 +35 @@
   packages (Binutils, GCC and Glibc). The small potential gains achieved in
   using compiler optimizations are often outweighed by the risks. First-time
-  builders of LFS are encouraged to build without custom optimizations.
+  builders of CLFS are encouraged to build without custom optimizations.
   The subsequent system will still run very fast and be stable at the
   same time.</para>
@@ -49 +49 @@
   removed.</para>
 
-  <para os="d">Before the installation instructions, each installation page
-  provides information about the package, including a concise
-  description of what it contains, approximately how long it will take
-  to build, how much disk space is required during this building
-  process, and any other packages needed to successfully build the
-  package. Following the installation instructions, there is a list of
-  programs and libraries (along with brief descriptions of these) that
-  the package installs.</para>
+  <para os="d">Before the installation instructions, each installation
+  page provides a concise description of what the package contains.
+  Following the installation instructions, there is a list of programs
+  and libraries (along with brief descriptions of these) that the
+  package installs.</para>
 
   <para os="e">To keep track of which package installs particular files, a

final-system/common/pkgmgt.xml

@@ -11 +11 @@
   <title>Package Management</title>
 
-  <para>Package Management is an often requested addition to the LFS Book. A
+  <para>Package Management is an often-requested addition to the CLFS Book. A
   Package Manager allows tracking the installation of files making it easy to
   remove and upgrade packages. Before you begin to wonder, NO&mdash;this section
@@ -20 +20 @@
   issues that may arise when upgrading packages.</para>
 
-  <para>Some reasons why no specific package manager is recommended in LFS or
-  BLFS include:</para>
+  <para>Some reasons why no specific package manager is recommended in
+  CLFS or BLFS include:</para>
 
   <itemizedlist>
@@ -44 +44 @@
 
     <para>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
+    are released. Generally the instructions in the CLFS and BLFS Book can be
     used to upgrade to the newer versions. Here are some points that you should
     be aware of when upgrading packages, especially on a running system.</para>
@@ -51 +51 @@
       <listitem>
         <para>If one of the toolchain packages (Glibc, GCC or Binutils) needs
-        to be upgraded to a newer minor version, it is safer to rebuild LFS.
-        Though, you <emphasis>may</emphasis> be able to get by 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.4
-        to glibc-2.3.5 will not usually cause any problems.</para>
+        to be upgraded to a newer minor version, it is safer to
+        rebuild CLFS. Though you <emphasis>may</emphasis> be able to get by
+        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.4 to glibc-2.3.5 will not
+        usually cause any problems.</para>
       </listitem>
 
@@ -229 +230 @@
       <title>User Based Management</title>
 
-      <para>This scheme, unique to LFS, was devised by Matthias Benkmann, and is
+      <para>This scheme, unique to the LFS project, was devised by Matthias Benkmann, and is
       available from the <ulink url="&hints-root;">Hints Project</ulink>. In
       this scheme, each package is installed as a separate user into the

final-system/x86/linux-headers.xml

@@ -26 +26 @@
     <title>Installation of Linux-Headers</title>
 
-    <para os="a">For years it has been common practice to use <quote>raw</quote>
-    kernel headers (straight from a kernel tarball) in <filename
-    class="directory">/usr/include</filename>, but over the last few
+    <para os="a">For years it has been common practice to use
+    <quote>raw</quote> kernel headers (straight from a kernel tarball) in
+    <filename class="directory">/usr/include</filename>, but over the last few
     years, the kernel developers have taken a strong stance that this
     should not be done. This gave birth to the Linux-Libc-Headers Project,
     which was designed to maintain an API stable version of the Linux
-    headers. But recently this project stopped producing updates. Cross-LFS
-    decided to come up with our own santized headers and placed them in
-    the book.</para>
+    headers. Recently this project stopped producing updates, so the Cross-LFS
+    team started development on our own project to sanitize the headers.</para>
 
     <para os="b">Install the header files that are common to all architectures:</para>