/usr vs /usr/local
bet at rahul.net
Wed Feb 2 09:19:29 PST 2005
I agree with everything Archaic said, would like to describe a
different slant on it, consistent with what he said but reflecting a
/usr/local/'s main role is really in relationships with vendor
distros. Vendors commit to stay the heck out of /usr/local/, and in
particular not to squish it on OS upgrades.
As a result of the above, the default install path for software
that people publish as add-on packages should be /usr/local. That's
why we have to override the default --prefix on each and every GNU
autoconf package. As an aside, my only gripe with autoconf in this
regard is that they don't have FHS-compliant subdir use, so we also
have to override --mandir, --infodir, --sysconfdir, etc.
Back to /usr/local, when using an OS with strong software packaging,
and using software packaging strictly for system configuration
management, if the OS is packaged and you package your add-ons
with the same packaging tool as the OS, it can make sense to leave
/usr/local completely empty, putting your add-ons, properly packaged
with the same tool as the OS, in /usr. I've been doing that for
years, first with rpm on Red Hat and now with bpm on Bent.
How does this associate with LFS?
I wouldn't suggest any *LFS modules or pkgs or whatever you call 'em
target /usr/local. In LFS, the user is the distro vendor. The book
might mention that when the user chooses to add things unrelated to
*LFS, packages that they've downloaded for themselves, they might
consider letting 'em default into /usr/local, so as to keep 'em
nicely policed up, easy to copy forward if they do a new LFS build.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the hlfs-dev