/usr vs /usr/local

Bennett Todd 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
different background.

/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.

-Bennett
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/hlfs-dev/attachments/20050202/ef3d1bde/attachment.sig>


More information about the hlfs-dev mailing list