Re: /usr/local policy
On Tue, 29 Feb 2000, Seth R Arnold wrote:
> Keep in mind though, Steve posted this not out of some higher moral
> purpose, but because some poor user's /usr/local was deleted by a script
> somewhere.
Yes and no.
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.
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.
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.
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?
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).
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. 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
/usr/local/lib/mon/mon.d
/usr/local/lib/mon/alert.d
/usr/local/lib/ghostscript/common
/usr/local/lib/ghostscript/5.10
/usr/local/stow
I won't know until I check the corresponding documentation in
/usr/share/doc. And that is the point: /usr/share/doc is THE PLACE for
documentation. An empty directory is a really weak form of documentation.
If I have to look in /usr/share/doc *anyway*, what is the point of
creating empty directories for me? It's just messy and confusing.
Moreover, packaging is such a complicated process that bugs relating to
the creation or removal of these directories are bound to happen
regularly.
To me it seems like pain for little to no gain.
It would be far cleaner to simply BAN meddling in /usr/local: besides
simplicity, this approach has the added virtue of actually respecting the
consensus on file system management reflected in the FHS!
> Maybe that script is non-compliant with Debian policy, but
> then maybe it is compliant.
For what it's worth, the *intent* of the package's upgrade script is
deemed to be in line with current policy; the execution, however, was
flawed.
Cheers,
--Steve
Reply to: