/usr/local vs. /usr/local/bin

[Jean-Francois Lamy]

In article <8504 at elsie.UUCP> ado at elsie.UUCP (Arthur David Olson) writes:
>What is the latest thinking on the directory that non-vendor executables
>should go in?  I've seen some packages that drop them into /usr/local
>and others that drop them into /usr/local/bin.

Current trends go towards /local/bin or /usr/local/bin.  Our local preference,
along the lines of SunOS4.0, is to have ...local/{bin,lib,share}.  Our
rationale for the split is as follows:

share: 	architecture independent stuff config/data/docs you don't want to
	replicate.
lib:	architecture dependent (*) libraries and executables
bin:    architecture dependent (*) executables.  This goes in user's path.

(*): we replicate shell/awk/perl/... scripts, because they are typically
installed by the same makefile that created binary executables and we feel
that using an interpreter instead of a compiled language is merely an
implementation choice (we often mutate programs from an sh prototype to a C
version.

A good rule of thumb is to keep in mind that even if you don't have a
mixed-architecture environment *now*, you may have one soon.  So write your
Makefiles and #defines with an explicit directory for architecture independent
configuration data and aux. files.  It costs little to simply define it
to be the same as the architecture dependent one if you so wish, but it will
make life much easier later.

>						If you have insights
>on the matter, I'd appreciate hearing from you by mail.

News provides a better soapbox :-).  Sure wish everyone who posts software
was stuck in an heteregeneous environment (there are Sun 2, 3 and 4, MIPS
and (gak) Ultrix uVaxen around here, all trying to run off the very same
source trees).

After "the world is a Vax" , is now time to stamp out the single-architecture
myth.

Jean-Francois Lamy               lamy at ai.utoronto.ca, uunet!ai.utoronto.ca!lamy
AI Group, Department of Computer Science, University of Toronto, Canada M5S 1A4