On Wed, Mar 01, 2000 at 01:10:37AM -0500, Steve Robbins wrote:
> It was the thread started by someone whose /usr/local got wiped out that
> started me thinking. However, I think there is a principle at stake here:
> the principle that /usr/local is LOCAL. Whatever the other faults with
> FHS, I (and others) think that they got this bit right: /usr/local ought
> to be left to the local admin alone.
This is a decent philosophical objection, and I can't think of any
arguments against it, on its own terms.
On other terms, the `existing practice' to make the directories is
somewhat helpful. I've added stuff to /usr/local/lib/texmf before, which
I'm sure was made much more trivial by not having to actually read the
docs and work out where it's meant to go. Wading through docs is all very
well, but, at least in some cases just having the directories already
sitting there waiting for you makes life easier.
> If packages persist in meddling with /usr/local, there is first of all the
> danger of bugs in the install or remove scripts. In my last message, I
> mentioned two or three threads in the past 18 months caused by such
> screwups.
One bug every six to nine months doesn't seem indicative of /that/
common an error, either.
Hmmm. And in the message that started this thread on policy I can only
see a reference to a single other case of it occuring, which concluded
`no, a policy change is unncessary, just fix emacs20'.
Note furthermore that both these packages directly violated policy in any
case, by adding these directories to the .deb rather than adding them in
the postinst. There is a lintian error about this.
> But even in a perfect bug-free world, creating and removing directories in
> /usr/local is a bad idea because it breaks the tradition that /usr/local
> is not touched by the OS. Besides annoying the admin, this could mess
> up some packages, like `stow' for example.
On the other hand, if stow didn't manipulate directories in /usr/local,
it wouldn't have any point at all.
> And for what? What is gained by creating empty directories in /usr/local?
> The policy document says this is "so that the system administrator knows
> where to place site-specific files." In other words, this is a kind of
> documentation. It's a rather bizarre form of documentation, though;
> what's wrong with using /usr/share/doc?
There's nothing wrong with /usr/share/doc. /usr/share/man is probably
more convenient (that what the FILES section is for, after all), but
there's nothing *wrong* with it.
What's *right* with doing it this way, is that it (theoretically) makes
life a bit easier for the admin. Being able to just cd into /usr/local
and hit tab a few times to work out where you want to add stuff is a
lot more user-friendly (for some users, at least) than having to poke
around through the documentation. And it's not like this is an either/or
choice, the documentation is generally there too.
> A couple people on -devel mentioned the example of finding the site
> directories for perl, python, or emacs by looking through the directories
> in /usr/local.
>
> However, this only works if you know a priori what you're looking for. I
> happen know that perl's site directories are typically named 'site_perl',
> so 'find /usr/local -name site_perl' works for me. If you weren't one of
> the perl cogniscenti, you might try 'ls /usr/local/lib/perl*' (which
> fails by the way).
"locate /usr/local/*perl*" seems to work pretty well. "find /usr/local
-type d -name '*perl*'" seems to too. Neither require you to be one of the
Perl cognoscenti.
> So you can only find what you already know. Creating empty directories
> does not help this admin if I don't know what they are for.
No, but that's not why it's done. It's done so that if you do know what
they're for, but you're not sure exactly where they're meant to be, you
can get a quick, easy, authoritative answer.
> Try running
> 'find /usr/local -empty -type d'. Some directories have an
> easily-guessable usage, but what the heck goes into these directories?
>
> /usr/local/share/games/fortunes/off
Offensive fortunes, a la the `fortunes-off' package.
> /usr/local/lib/mon/mon.d
> /usr/local/lib/mon/alert.d
Presumably extra stuff for the `mon' package. I'm sure if you were
actually trying to add stuff to mon you'd know exactly what was to
go here. Possibly hosts to monitor and alerts to send.
> /usr/local/lib/ghostscript/common
> /usr/local/lib/ghostscript/5.10
/usr/lib/ghostscript/{common,5.10} exist, and seem to contain printer
defintion files and the like.
> /usr/local/stow
Package: stow
Description: Organiser for /usr/local/ hierarchy
GNU Stow helps the system administrator organise files under /usr/local/
by allowing each piece of software to be installed in its own tree under
/usr/local/stow/, and then using symlinks to create the illusion that
all the software is installed in the same place.
In short, I don't really think you have any arguments here except the
philosophical one. Yes, bugs happen: but we're already doing a reasonable
job of avoiding that with the lintian error and the advice about how
to do things properly in policy, and we've only had it occur twice, in
unstable, in a bit over a year. Even better, this bug at worst causes a
symlink or an empty directory to disappear. That's not a major catastrophe
(not as bad as, say, accidently chown'ing everything below / to root,
which has happened).
Personally, I think the practical considerations ("hey neat, the
directory's already there for me") outweigh the philosophical here.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG encrypted mail preferred.
``The thing is: trying to be too generic is EVIL. It's stupid, it
results in slower code, and it results in more bugs.''
-- Linus Torvalds
Attachment:
pgpJtqzhiBJfr.pgp
Description: PGP signature