Re: /usr/local again
> On Mon, Feb 14, 2000 at 08:08:40PM +0000, Dale Scheetz wrote:
>
> > Why not treat these directories the same way we treat configuration files.
> > That is, the directories remain, under a normal Remove, but are "properly"
> > removed if a Purge is requested. This leaves the control in the hands of
> > the admin, where it belongs.
I don't understand how this improves on the current handling of /usr/local
directories. In fact, it sounds worse: if I'm offended by a package
creating empty directories to begin with, I'd be even more annoyed if
they stick around after a "normal Remove"! :-)
Let's go back and look at the more fundamental question. Why do Debian
packages create empty directories in /usr/local? Answer: the Policy
allows them to.
But the policy document provides no rationale for this position. I was
hoping this thread would uncover the reasoning behind it. As best as I
can gather from the Debian Status Quo proponents, creating these
directories is a form of documentation. A couple people have mentioned
the example of finding the site directories for perl, python, and emacs.
This is a weak argument.
To start with, 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. A better solution is to
try reading /usr/share/doc/perl-something. However, if you _really_ were
a perl guru, you'd just run 'perl -V', and perl itself will tell you where
it is looking for modules and libraries. There is no need to go hunting
on the filesystem. Emacs, too, will tell you what its load-path is if you
ask it. (I don't use python, but perhaps it has a similar mechanism).
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.
On Tue, 15 Feb 2000, Torsten Landschoff wrote [in response to the piece by
Dale Scheetz, quoted above]:
> Okay, let's end this thread now. I agree this sounds sane. When I get the
> time I will write a little script to handle /usr/local from package
> scripts.
Great. We complain that Debian encroaches on OUR space, and your answer
is to put more Debian machinery there! ;-)
I'll remind you that this whole thread got started because upgrading
ghostscript broke someone's /usr/local. Packaging is already tricky
enough. Adding complexity is unlikely to improve the robustness.
There is a much simpler solution: FORBID packages to do anything to
/usr/local. Besides simplicity, this approach has the added virtue of
actually respecting the consensus on file system management reflected in
the FHS!
A lot of us like the idea that /usr/local belongs to the LOCAL admin.
That means: "keep yer hands off it, debian". Completely and absolutely.
This is not impossible to do: no packages mess with files in /home, do
they?
The strongest argument for this stance is that it gives the local admin a
kind of "peace of mind" when upgrading a package. I don't have to worry
that some random directory is going to get created. This could, to use
Brian May's example, mess up stow. Or I might be running tripwire on
/usr/local; I'd be quite annoyed if installing a package in /usr trips
alarms in /usr/local. Or maybe I just have this irrational desire to know
what each and every file or directory on /usr/local is for. Whatever. It
reduces my mental load if I can trust that Debian religiously keeps
away from /usr/local.
And finally: while writing this note, I discovered a file named
/usr/local/lib/texmf/ls-R. I didn't create this. Nor did I create the
directory /usr/local/lib/texmf, to the best of my knowledge. I presume
that some part of tex once created the directory, and some other part
created the file. Probably both pieces were following Policy, but
conspired to violate it behind my back: installing a package created a
file in /usr/local.
I'll leave this as another example of how a complicated packaging system
can have unexpected consequences. Sure, bugs can be fixed one by one.
But it is simpler, in my mind, to simply RESPECT the FHS, and FORBID
packages from doing anything to /usr/local.
Cheers,
-Steve
Reply to: