From: pgr@prg.ox.ac.uk (Phil Richards) Subject: Re: No /usr/local please (Would you please Shut Up?) Date: 21 Sep 1992 13:23:47 GMT
Long and boring reply... hit `n' now if you can't cope with yet another
article in this series... it's sort of a counter-flame, but my heart
isn't really in it :-} This isn't really the most major problem in my
life at the moment :-)
In <1992Sep21.083039.1307@newshost.anu.edu.au>, Matthew McDonald
<matthew@psych.psy.uq.oz.au> writes:
> Well, its a bit late to whine about it now. The standards people
> decided this a long time ago. If you were around then, you should have
> taken part in the discussion. If you weren't around at the time - tough
> luck - you're too late.
Oh good. I'm so glad that you are taking such a flexible and generous
attitude. It is *not* too late to change things -- this is still Beta
test remember? Since the decision has been *so* well publicised, I'm
surprised that so many people still haven't heard about it. Or was it
only publicised on the mailing list? (Rhetorical question -- if such
an important decision was made it should be rather well publicised in
one of the FAQ's... as far as I can remember from my last perusal of the
FAQ's no mention is made. Standards are of no use if the community as a
whole isn't told.) The assumption that all people compiling up software
are going to be on the standards mailing list is not a particularly good
one (especially considering the mailing lists success rate at agreeing
standards...).
[...]
> /usr/local is basically just somewhere TeX is relatively safe from
> being overwritten during upgrades. Understand?
So? This doesn't contradict anything I said; in fact, I actually *agree*
with you. (Btw, I'm not actually stupid... you can assume I have a little
knowledge about Unix and software installation.) This in itself, however,
is not a justification for merging /usr and /usr/local completely.
> > Why create another arbitrary directory which is completely unique to
> > Linux, and will require that all code that is compiled will have to
> > be modified in order to compile?
> ^^^^
> This sentence not parse. I have no idea what you were trying to say.
Ok, I'll try again. If you pick up a package, the chances are that,
by default, it will try to install itself in /usr/local. Therefore,
in order to compile it to install somewhere else, you have to modify it
so that it installs elsewhere. In other words, `code that is compiled
will have to be modified'. The reason why it has to be modified is
`in order for it to compile' and install into the correct place (sorry
for missing the last bit out; I assumed it was obvious). I was using
`code' for both `executable' and `source'. Sorry for confusing you.
(Btw, the sentence does seem to parse to me -- but then again, I wrote
it so I'm biased.)
[... about putting TeX and X in /usr/TeX and /usr/X ...]
>Of course if you did that, you'd have long PATHs (or lots of
>shambolic links in /bin), but long PATHs shouldn't cause any problems - surely.
And it wouldn't be too dumb an idea, apart from the fact that things
tend to look in /usr/local for things... (e.g., GNU fontutils assumes
the TeX/Metafont stuff is under /usr/local).
(In fact, my preference would be for that -- but I'm pragmatic about it.
If I build my directory tree in that way, things will break because they
look in the wrong place. I prefer the easier solution of going with the
flow of `normal'[sic] Unix.)
> Sorry for the flame but I'm pissed off at all the people who feel
> they really gotta explain to everyone how to set up a a Unix clone.
Actually, I thought I was giving an opinion. One which seems to apply to
most Unix systems I've used; and one which seems to have a certain amount
of logic behind it. By keeping with the /usr, /usr/local distinction,
people will be a little less surprised when moving between Linux and
other Unix systems (and with networking being added this becomes a little
more important).
I still haven't seen a reason why *having* /usr/local causes any problems.
Yes, there are aesthetic arguments (it's nicer to have everything in
/usr/bin), but there don't seem to be any problems caused by preserving
the separation. There *do* however seem to be quite valid reasons why
not to merge the two (for compatability etc) which do cause problems if
the distinction is removed (like more hand editting of config output).
> (That and no sleep in 48 hours...)
Ditto. Except that is now -- I wrote the original article when I was
coherent.
NOTE: followup's have been directed to `poster'... if you wish to make
a non-flame comment, then change the Newsgroup line... otherwise, flame
by mail. This article is more than pollution enough...
phil "who would have responded by mail if I had been awake"