source: introduction/important/position.xml@ 1d85838

10.0 10.1 11.0 11.1 6.0 6.1 6.2 6.2.0 6.2.0-rc1 6.2.0-rc2 6.3 6.3-rc1 6.3-rc2 6.3-rc3 7.10 7.4 7.5 7.6 7.6-blfs 7.6-systemd 7.7 7.8 7.9 8.0 8.1 8.2 8.3 8.4 9.0 9.1 basic bdubbs/svn elogind gnome kde5-13430 kde5-14269 kde5-14686 krejzi/svn lazarus nosym perl-modules qt5new systemd-11177 systemd-13485 trunk upgradedb v5_0 v5_0-pre1 v5_1 v5_1-pre1 xry111/intltool xry111/test-20220226
Last change on this file since 1d85838 was b77b166f, checked in by Larry Lawrence <larry@…>, 19 years ago

more spellcheck

git-svn-id: svn:// af4574ff-66df-0310-9fd7-8a98e5e911e0

  • Property mode set to 100644
File size: 3.5 KB
1<sect1 id="intro-important-position">
2<?dbhtml filename="position.html" dir="introduction"?>
3<title>The /usr versus /usr/local debate</title>
5<para><emphasis>Should I install XXX in /usr or
8<para>This is a question without an obvious answer for an LFS based
11<para>In traditional unix systems, <filename>/usr</filename> usually
12contains files that come
13with the system distribution, and the <filename>/usr/local</filename> tree
14is free for the local administrator to add things to. The only
15really hard and fast
16rule is that unix distributions should not touch
17<filename>/usr/local</filename>, except
18perhaps for creating the basic directories within it.</para>
20<para>With Linux distributions, like Red Hat, Debian etc. a possible rule is
21that <filename>/usr</filename> is managed by the distribution's
22package system and <filename>/usr/local</filename> is not. This way the
23package manager's database knows about every file within
26<para>LFS users build their own system and so deciding where the system ends
27and local files begin is not straightforward. So the choice should be
28made in order to make things easier to administer. There are several
29reasons for dividing files between <filename>/usr</filename> and
34<listitem><para>On a network of several machines all running LFS, or mixed
35LFS and
36other Linux distributions, <filename>/usr/local</filename> could be used to
37hold packages
38that are common between all the computers in the network. It can be
39NFS mounted or mirrored from a single server. Here local indicates
40local to the site.</para></listitem>
42<listitem><para>On a network of several computers all running an identical
43LFS system <filename>/usr/local</filename> could hold packages that
44are different between the machines. In this case local refers to
45the individual computers.</para></listitem>
47<listitem><para>Even on a single computer <filename>/usr/local</filename> can
48be useful if you have several distributions installed simultaneously, and want
49a place to put packages that will be the same on all of
52<listitem><para>Or you might regularly rebuild your LFS, but want
53a place to put files
54that you don't want to rebuild each time. This way you can wipe the
55LFS filesystem and start from a clean partition every time without losing
60<para>Some people ask why not use your own directory tree, e.g.
61<filename>/usr/site</filename> rather than
64<para>There is nothing stopping you, many sites do make their own trees, however
65it makes installing new software more difficult. Automatic installers
66often look for dependencies in <filename>/usr</filename> and
67<filename>/usr/local</filename>, and if the file it is looking
68for is in <filename>/usr/site</filename> instead, the installer will
69probably fail unless
70you specifically tell it where to look.</para>
72<para><emphasis>What is the BLFS position on this?</emphasis></para>
74<para>All of the BLFS instructions install programs in
75<filename>/usr</filename> unless specifically stated otherwise. There
76are examples where some files are placed in the
77<filename>/usr/local</filename> hierarchy but these are documented and
78are generally for a good reason. These exceptions should be well documented
79in the book. If you think you have
80found one which isn't please tell us!</para>
Note: See TracBrowser for help on using the repository browser.