From: furnish@ccwf.cc.utexas.edu (Geoffrey Furnish)
Newsgroups: comp.os.linux
Subject: Re: No /usr/local please (Re: Help: Need TeX/LaTeX linked with jump table 4.1)
Date: 26 Sep 92 15:10:48 GMT
Organization: The University of Texas at Austin, Austin TX

In article <15497@borg.cs.unc.edu> faith@cs.unc.edu (Rik Faith) writes:

>We've been through this countless times (on this newsgroup and on the
>linux-standards mailing list).

>The general consensus from the linux-standards list was that /usr/local
>should be used for stuff that is local to *YOUR* machine, and *NOT* for
>stuff that is distributed for the community.

Well then the linux-standards is WRONG !!!  I obviously don't speak
for everyone, but at least some of us out there think this is a
very BAD decision.

>Therefore, the TeX distribution belongs in /usr and *NOT* in /usr/local.
>However, your personal, hacked-up copy of TeX belongs in /usr/local.

Ballogney.  TeX (at least Unix TeX, which I assume is what we're
talking about here) comes preconfigured for use under usr/local, and
all of the good dviware I have seen makes similar assumptions.  To
change that means going into the makefiles and changing all kinds of
stuff.  But it's hard to know if you got it all straight, and whenever
something can't find it's format files or whatever, you have to go
searching all over creation to figure out what got screwed up.  It's a
major hassal.

So, you might say, big deal--if it comes precompiled why would anyone
care?  Because, someone might need to add a new dvitool or something
on just their system.  And if all the Linux TeX stuff is in the
"wrong" place (i.e., not usr/local) then it can be unnecessarily
frustrating to make it work.

>*ALL* the GNU utilities belong under /bin or /usr/bin, since these are the
>"standard" Linux utilities.  Likewise, other large, monolithic pieces of
>software (i.e., TeX, and X11) are part of a "standard" Linux installation
>and belong in trees under / and /usr, but *NOT* under /usr/local.

Things which are replacements for standard unix tools, should go in
the place where the standard unix tool goes.  Thats what a replacement
is.  TeX and friends are NOT "standard unix things".  They go in
/usr/local on all other vendor supplided unices, and they should go in
the same place on Linux.

I don't know about other Linuxers, but I have to manage several Unix
systems in addition to my home Linux box.  I find that putting non
essential (i.e., you don't need it to boot, do basic things, etc)
things in /usr/local is a real blessing from a management perspective.
I simply am baffled at why anyone would want to junk up the /usr and
/usr/bin directories on Linux with all kinds of stuff which doesn't
belong there.

Perhaps an ancedote is in order.  Several years ago I managed a VMS
center.  On VMS, all system executables go in one directory, called
sys$exe.  Dec decided that _ALL_ comercial packages should have their
insall scripts put things in sys$exe, and they were so serious about
this that they developed a standard package installation facility
(called vmsinstall) and distributed it to anyone who made software for
VMS systems.  Whenever a vendor used vmsinstall, it was absolutely
impossible to get the products to go into any directory other than
sys$exe.  Finally, due to the way that the VMS shell worked, in order
for a command to be available, a modification had to be made to the
shell to insert the new command into the command tables.  This file
was called sys$exe:dcltables.exe.  One day my coworkder installed a
vendor supplied package which was developed by a bunch of incompetent
ninies.  Somehow they managed to screw up the installation in such a
way that the sys$exe:dcltables.exe on disk was corrupted.  Since it
was an "installed" program the system continued to use the one in
memory, and no problem was noticed.  UNTIL one day a month later when
we had to reboo the system.  Only problem was, it wouldn't boot !!!
We couldn't figure out what was wrong.  The entire computation cener
was shut down for three days because we couldn't boot the stupid os.
Eventually we finally found that the dcltables had been corrupted, and
we were able to figure out how it was done.

The point is, if it had been possible to install programs in some
directory other than sys$exe, and to keep modified shells somewhere
else, then the system would not have been vulnerable to a corrupted
shell command table (vms equivalent of a botched path in unix).  But
by forcing all new executables to go in the same place, a management
nightmare was constructed, and occasionally things got sick.

It is for the same reason that unix systems put non essential things
in /usr/local.  That way they won't screw up the entire system so
that it is unusable if something gets fouled up.  Its fundamentally a
management decision, designed to improve the integrity of systems.
Throwing this out in Linux means that fouled up installations will be
mucking around with system directories, and ultimately Linux will be
less stable because of it.  Sure, I know, it works fine when it works.
But the point is sometimes things go wrong.  And when things go wrong,
you want them to go wrong somewhere where it isn't going to criplle
the system.  Keeping unnecessary things out of /usr and /usr/bin is a
great first start.

>-- 
>Rik Faith: faith@cs.unc.edu
>What I tell you three times is true.  --Dodgson

Geoff Furnish
furnish@dino.ph.utexas.edu