comp.unix.admin.large

[Piercarlo Grandi]

On 18 Dec 90 02:06:56 GMT, arnold at mango.synopsys.com (Arnold de Leon) said:

arnold> I am in the process of redesigning the way provide
arnold> /usr/local/{bin,etc,lib,man} Here is what I have in mind

arnold>         o automount /usr/local

Surely you jest... You always want it mounted :-).

arnold>         o any 'package' containing more than one binary would be
arnold>           installed in it's own directory.
arnold>                 Example:  perl
arnold>                         /usr/local/perl/{bin,lib,man} would be created.
arnold>                         The contents of /usr/local/perl/{bin,lib,man}
arnold>                         would be symlinked to /usr/local/{bin,lib,man}
arnold>                         as needed.

arnold>         o a side-effect is /usr/local/bin will be mostly symbolic links

This is a popular choice which is particularly ill advised. Don't do it.
Too many mount points, too many little and tall directories and
symlinks.  It is a bad bad idea. For efficiency and operability.

In general also symlinks are a poor and silly idea that creates
maintenance nightmares. It is better to think harder (something that
manucfacturers of Unix workstations seem bad at) and shaep a more
appropriate tree. Moreover hard links should be used wherever possible
in place of symbolic links.

What you want is to start having some /usr/local/src directory, which
contains a directory called 'commands' for small one source+one man page
commands, and then a separate source directory for each larger package.
You want to do traditional install of the resulting binaries, libraries,
manual pages, ...  You also want to have remove scripts.  Unfortunately
most packages come with poor makefiles that do not have them.

You want to create *exact* duplicates of the installed tree if you need
redundancy without admin headaches. Don't be clever -- don't customize
for each and every workstation group or similar. I would create a
/usr/local tree like this:

    /usr/local
    /usr/local/bin			commands
    /usr/local/lib			libraries
    /usr/local/lib/perl			Perl library sources
    /usr/local/lib/emacs.lisp		GNU Emacs standard .elc
    ...
    /usr/local/etc			system commands
    /usr/local/man
    /usr/local/man/info			info files (not just GNU Emacs')
    /usr/local/man/man[1-9]		manual pages

How to make this configurable by machine and operating system type? I
suggest having, propagated from /etc/init, two environment variables,
CPU (e.g. SPARC, i386, MIPS, 68010, 68040, ..) and OS (e.g. SVR3.2,
Xenix, SunOS 4, Ultrix 4, Next 2), and creating directories with the
values of those two environment variables in them.

This could be done as either "/usr/local.$CPU.$OS", and then you have
the whole tree keyed on those two, or you key the subdirectories, e.g.
as "/usr/local/bin.$CPU.$OS".  It's a difficult choice really. For small
installations I'd go for the latter, specialized subtrees of /usr/local,
for largish ones I'd go for specialized /usr/local trees.

You also want to have architecture and (or) operating system independent
directories, e.g. for shell scripts. If you need to have a shell script
that works on multiple architectures, it is much better for it to check
the values of CPU and OS internally than to have different versions for
each combination.

Unfortunately many packages come with installation procedures that do
not distinguish between architecture and ooperating system dependent
thigns and those that are. For example in GNU Emacs's etc directory you
will find mixed things like loadst, which is an executable, with DOC,
which is machine independent.

Using some powerful make, like dmake or cake, is best, as you can do
conditional make'ing and installation based on the values of CPU and OS
and keep objects and libraries for different combinations in different
directories.

Finally I would put in people's environment a LOCAL variable to point at
the right /usr/local, and in their PATHs and similar both the machine
independent and the machine dependent subtrees keyed on CPU and OS; for
example

	PATH="$LOCAL/bin.$CPU.$OS:$LOCAL/bin:/bin:/usr/bin:."
or
	PATH="$LOCAL.$CPU.$OS/bin:$LOCAL/bin:/bin:/usr/bin:."

A clever scheme, that allows you to switch between the two, is to have a
third environment variable, say WHERE, which is used like this:

	WHERE="/$CPU.$OS."
or
	WHERE=".$CPU.$OS/"

with

	PATH="${LOCAL}${WHERE}bin:${LOCAL}/bin:/bin:/usr/bin:."

If you go for specialized /usr/local trees then you need to mount *two*
for each machine, the unspecialized and the specialized one. If you go
for specialized subtrees, you can just mount the entire /usr/local tree,
the right subtrees will be used by looking at OS and CPU.

And so on. I wish that manufacturers in their recent reshaping of the
traditional UNIX tree had been cleverer and packed together files
according to criteria like:

	read-only-ness			(e.g. /bin, /lib, ...)

	version dependency		(e.g. some of /lib, some of /usr/man)

	host dependency			(e.g. some of /usr/etc)

	site dependency			(e.g. some of /etc, some of /usr/lib)

	expendability			(e.g. /tmp, many /usr/spool or /usr/adm)

	CPU and OS independence		(e.g. a lot of /usr/man)

	need of periodic attention	(e.g. a lot of /usr/adm)

For example a lot of configuration files should most most definitely not
be in /usr/lib, and a lot of sysadmin executables should not be in /etc
or /usr/etc, and what goes in /usr/adm is hopelessly confused with what
goes in /usr/spool (actually /usr/adm should be /usr/spool/logs), and so
on. System V.3 is a particularly bad offender, it put lp congifuration
files and executables and logs all under /usr/spool, and puts mail and
preserve under /usr instead of /usr/spool, and puts executables in
/usr/lib, ...

In practice the recent reorganization has been done along the
read-only/variable line. Hum. A lot of packages that scatter their
things all around the tree have been left alone. Bah.
--
Piercarlo Grandi                   | ARPA: pcg%uk.ac.aber.cs at nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg at cs.aber.ac.uk