comp.unix.admin.large

[Bruce Barnett]

With everyone talking about /usr/local, I thought I would throw in my
2 cents.

We support several different architectures, and having a unique
/usr/local isn't always the most efficient way to organize disk space.
Some files can be shared across architectures, others can't. The ones
that can be shared are easier to maintain when they are only in one location.

We use /usr/local for workgroup specific additions, changes, in
addition to a large /common area - used throughout the center.

Some applications put multiple architectures in one place, others use
two seperate places. Our organization:

/common/all - architecture independant or multiple architecture
	installations, includes:
/common/all/bin - for shell/perl scripts
/common/all/lib - ASCII data used by all architectures.
/common/all/emacs - for common emacs lisp and info files
/common/all/frame - for sun3 and sun4 binaries of framemaker 

We also have a /common/`arch` directory for each popular architecture:
	/common/sun3, /common/sun4, /common/vax, etc.

This way people can put /common/`arch`/bin and /common/all/bin
in their searchpath, in addition to /usr/local - if they want to.

As someone who has installed hundreds of programs, this organization
works out fine. In some cases when it is not clear where a file should
be installed (i.e. in /common/all/lib or /common/sun4/lib, I just use
the architecture specific directory with the knowledge that I might
have a few redundant files in /common/sun3/lib and /common/sun4/lib

Having both directories mounted makes it easier to see if there are
common files in both architectures.link - either hard or symbolic -
can help eliminate duplicated files.
 

 
--
Bruce G. Barnett	barnett at crd.ge.com	uunet!crdgw1!barnett