I made some inappropriate comments (for this mailing list) on the use
of /usr/local versus some brand new path idea. Some people asked me
to explain why I advise against /usr/local.
1. putting things under /usr is an artifact of the early PDP-11
implementations and doesn't really make sense in the days of
tens-of-gigs fileservers.
2. the berkeley automount daemon AMD, which is quite good and is
probably the only automouter that comes close to working well,
right now requires a single-depth path for mount points so that you
can use the transparent "/n/hostname/path" formalism.
3. when you come in to a new group, they almost always have a
spaghetti-like tangle in /usr/local already. It is usually better
to ignore it, set up your /central (or whatever), put it first in
paths, and slowly rebuild all the utilities you need. Then phase
the existing out /usr/local.
4. some people argue (I don't care) that "local" should really be on
the "local machine's disk". some bad software can only run on a
truly local disk, like UNIX autocad for example. "/usr/central"
would be a little better in this sense.
For all these reasons, the way we have set things up in our division
in Los Alamos (http://nis-www.lanl.gov/admin/procedures.html) uses
/packages (for free software) and /vendor (for proprietary packages).
We actually go further and use a complex setup to allow for the
multiple architectures sharing non-binary stuff, but the paths people
see are /packages and /n/vendor (for historical reasons /packages does
not have a /n: we started using amd after we already had that path).
So I would recommend that people use a path like /central or /packages
or /vendor rather than /usr/local.
John> Would you care to point me at the rationale on /packages?
John> (Came up with the idea of [packages.] subtrees on my own for
John> third party stuff under VMS. Never heard of anyone else
John> doing it. Would love to hear some justification.)
>> Note: I always recommend that people not use
>> /usr/local/{bin,lib,...}, but rather a prefix like /packages or
>> /central or whatever. There are several reasons for this, and
>> if you don't have a big established /usr/local, I would not use
>> it.