Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.unix.admin Subject: Re: comp.unix.admin.large Message-ID: Date: 27 Dec 90 19:10:00 GMT References: <609@synopsys.COM> Sender: pcg@aber-cs.UUCP Followup-To: comp.unix.admin Organization: Coleg Prifysgol Cymru Lines: 140 Nntp-Posting-Host: teachk In-reply-to: arnold@mango.synopsys.com's message of 18 Dec 90 02:06:56 GMT On 18 Dec 90 02:06:56 GMT, arnold@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@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk