Author: manuel Date: 2005-05-07 06:12:52 -0600 (Sat, 07 May 2005) New Revision: 4015
Modified: trunk/BOOK/introduction/important/position.xml Log: Tagged position.xml Modified: trunk/BOOK/introduction/important/position.xml =================================================================== --- trunk/BOOK/introduction/important/position.xml 2005-05-07 12:07:44 UTC (rev 4014) +++ trunk/BOOK/introduction/important/position.xml 2005-05-07 12:12:52 UTC (rev 4015) @@ -6,78 +6,82 @@ ]> <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>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> -<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> - </sect1> -- http://linuxfromscratch.org/mailman/listinfo/blfs-book FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
