source: BOOK/final-system/common/introduction.xml@ 9f696aca

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
  "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
  <!ENTITY % general-entities SYSTEM "../../general.ent">
  %general-entities;
]>

<sect1 id="ch-system-introduction">
  <?dbhtml filename="introduction.html"?>

  <title>Introduction</title>

  <para os="a">In this chapter, we enter the building site and start
  constructing the LFS 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
  to provide the full instructions for every package to minimize the
  possibilities for mistakes.  The key to learning what makes a Linux
  system work is to know what each package is used for and why the user
  (or the system) needs it.  For every installed package, a summary of
  its contents is given, followed by concise descriptions of each
  program and library the package installed.</para>

  <para os="b">If using the compiler optimizations provided in this chapter,
  please review the optimization hint at <ulink
  url="&hints-root;optimization.txt"/>.  Compiler optimizations can make
  a program run slightly faster, but they may also cause compilation
  difficulties and problems when running the program. If a package
  refuses to compile when using optimization, try to compile it without
  optimization and see if that fixes the problem. Even if the package
  does compile when using optimization, there is the risk it may have
  been compiled incorrectly because of the complex interactions between
  the code and build tools.  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.
  The subsequent system will still run very fast and be stable at the
  same time.</para>

  <para os="c">The order that packages are installed in this chapter needs to
  be strictly followed to ensure that no program accidentally acquires a
  path referring to <filename class="directory">/tools</filename>
  hard-wired into it. For the same reason, do not compile packages in
  parallel. Compiling in parallel may save time (especially on dual-CPU
  machines), but it could result in a program containing a hard-wired
  path to <filename class="directory">/tools</filename>, which will
  cause the program to stop working when that directory is
  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="e">To keep track of which package installs particular files, a package
  manager can be used. For a general overview of different styles of package
  managers, please refer to <ulink
  url="&blfs-root;view/svn/introduction/important.html"/>.
  For a package management method specifically geared towards LFS, we
  recommend <ulink url="&hints-root;more_control_and_pkg_man.txt"/>.</para>

  <note os="f">
    <para>The remainder of this book is to be performed while logged
    in as user <systemitem class="username">root</systemitem> and no longer
    as user <systemitem class="username">lfs</systemitem>.</para>
  </note>

</sect1>