Index: introduction/important/position.xml
===================================================================
--- introduction/important/position.xml	(revision 1f2436394c4ba4a76f469a62d24ff9a0857056ec)
+++ introduction/important/position.xml	(revision d5f2a3f4c950769971709ad7b305c0b539c0191f)
@@ -7,77 +7,81 @@
 
 <sect1 id="intro-important-position">
-<sect1info>
-<othername>$LastChangedBy$</othername>
-<date>$Date$</date>
-</sect1info>
-<?dbhtml filename="position.html"?>
-<title>The /usr versus /usr/local debate</title>
+  <?dbhtml filename="position.html"?>
 
-<para><emphasis>Should I install XXX in <filename>/usr</filename> or
-<filename>/usr/local</filename>?</emphasis></para>
+  <sect1info>
+    <othername>$LastChangedBy$</othername>
+    <date>$Date$</date>
+  </sect1info>
 
-<para>This is a question without an obvious answer for an
-<acronym>LFS</acronym> based system.</para>
+  <title>The /usr Versus /usr/local Debate</title>
 
-<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 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><emphasis>Should I install XXX in <filename>/usr</filename> or
+  <filename>/usr/local</filename>?</emphasis></para>
 
-<para>With Linux distributions, like Red Hat, Debian etc. a possible rule is
-that <filename>/usr</filename> is managed by the distribution's 
-package system and <filename>/usr/local</filename> is not.  This way the 
-package manager's database knows about every file within
-<filename>/usr</filename>.</para>
+  <para>This is a question without an obvious answer for an
+  LFS based system.</para>
 
-<para><acronym>LFS</acronym> users build their own system and so deciding where 
-the system ends and local files begin is not straightforward.  So the choice 
-should be made in order to make things easier to administer.  There are several
-reasons for dividing files between <filename>/usr</filename> and
-<filename>/usr/local</filename>.</para>
+  <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 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>
 
-<itemizedlist>
+  <para>With Linux distributions, like Red Hat, Debian etc. a possible rule is
+  that <filename>/usr</filename> is managed by the distribution's 
+  package system and <filename>/usr/local</filename> is not.  This way the 
+  package manager's database knows about every file within
+  <filename>/usr</filename>.</para>
 
-<listitem><para>On a network of several machines all running <acronym>LFS</acronym>, 
-or mixed <acronym>LFS</acronym> and other Linux distributions, 
-<filename>/usr/local</filename> could be used to hold packages
-that are common between all the computers in the network.  It can be
-<acronym>NFS</acronym> mounted or mirrored from a single server.  Here local 
-indicates local to the site.</para></listitem>
+  <para>LFS users build their own system and so deciding where 
+  the system ends and local files begin is not straightforward.  So the choice 
+  should be made in order to make things easier to administer.  There are several
+  reasons for dividing files between <filename>/usr</filename> and
+  <filename>/usr/local</filename>.</para>
 
-<listitem><para>On a network of several computers all running an identical 
-<acronym>LFS</acronym> system <filename>/usr/local</filename> could hold 
-packages that are different between the machines.  In this case local refers 
-to the individual computers.</para></listitem>
+  <itemizedlist>
+    <listitem>
+      <para>On a network of several machines all running LFS, 
+      or mixed LFS and other Linux distributions, 
+      <filename>/usr/local</filename> could be used to hold packages
+      that are common between all the computers in the network.  It can be
+      NFS mounted or mirrored from a single server.  Here local 
+      indicates local to the site.</para>
+    </listitem>
+    <listitem>
+      <para>On a network of several computers all running an identical 
+      LFS system <filename>/usr/local</filename> could hold 
+      packages that are different between the machines.  In this case local refers 
+      to the individual computers.</para>
+    </listitem>
+    <listitem>
+      <para>Even on a single computer <filename>/usr/local</filename> can 
+      be useful if you have several distributions installed simultaneously, and want 
+      a place to put packages that will be the same on all of them.</para>
+    </listitem>
+    <listitem>
+      <para>Or you might regularly rebuild your LFS, but 
+      want a place to put files that you don't want to rebuild each time.  This way 
+      you can wipe the LFS file system and start from a clean 
+      partition every time without losing everything.</para>
+    </listitem>
+  </itemizedlist>
 
-<listitem><para>Even on a single computer <filename>/usr/local</filename> can 
-be useful if you have several distributions installed simultaneously, and want 
-a place to put packages that will be the same on all of them.</para></listitem>
+  <para>Some people ask why not use your own directory tree, e.g., <filename>
+  /usr/site</filename>, rather than <filename>/usr/local</filename>?</para>
 
-<listitem><para>Or you might regularly rebuild your <acronym>LFS</acronym>, but 
-want a place to put files that you don't want to rebuild each time.  This way 
-you can wipe the <acronym>LFS</acronym> file system and start from a clean 
-partition every time without losing everything.</para></listitem>
+  <para>There is nothing stopping you, many sites do make their own trees, 
+  however it makes installing new software more difficult.  Automatic installers
+  often look for dependencies in <filename>/usr</filename> and
+  <filename>/usr/local</filename>, and if the file it is looking
+  for is in <filename>/usr/site</filename> instead, the installer will 
+  probably fail unless you specifically tell it where to look.</para>
 
-</itemizedlist>
+  <para><emphasis>What is the BLFS position on this?</emphasis></para>
 
-<para>Some people ask why not use your own directory tree, e.g., <filename>
-/usr/site</filename>, rather than <filename>/usr/local</filename>?</para>
-
-<para>There is nothing stopping you, many sites do make their own trees, 
-however it makes installing new software more difficult.  Automatic installers
-often look for dependencies in <filename>/usr</filename> and
-<filename>/usr/local</filename>, and if the file it is looking
-for is in <filename>/usr/site</filename> instead, the installer will 
-probably fail unless you specifically tell it where to look.</para>
-
-<para><emphasis>What is the <acronym>BLFS</acronym> position on this?</emphasis>
-</para>
-
-<para>All of the <acronym>BLFS</acronym> instructions install programs in
-<filename>/usr</filename> with optional instructions to install into
-<filename>/opt</filename> for some specific packages.</para>
+  <para>All of the BLFS instructions install programs in
+  <filename>/usr</filename> with optional instructions to install into
+  <filename>/opt</filename> for some specific packages.</para>
 
 </sect1>
