Re: /usr/local again
On Wed, 9 Feb 2000, Jordi wrote:
> On Wed, Feb 09, 2000 at 09:55:45AM +1100, Brian May wrote:
> > IMHO, /usr/local should be for local system administrator use, and no
> > package should ever touch it (although setting up default search paths
> > to include /usr/local is probably a good idea).
>
> From Debian-Policy:
>
> However, the package should create empty directories below /usr/local
> so that the system administrator knows where to place site-specific
> files. These directories should be removed on package removal if they
> are empty.
> [...]
> Since /usr/local may be mounted read-only from a remote server, these
> directories have to be created and removed by the postinst and prerm
> maintainer scripts. These scripts must not fail if either of these
> operations fail. (In the future, it will be possible to tell dpkg not
> to unpack files matching certain patterns, so that the directories can
> be included in the .deb packages and system administrators who do not
> wish these directories in /usr/local do not need to have them.)
>
>
> So, as someone said before, if the package only removes directories below
> /usr/local, it should be ok if the script does not fail even if it cannot
> write/delete there.
I disagree with the notion that a package out to be messing around with
/usr/local AT ALL. Not even creating or removing directories.
Creating and removing empty directories _sounds_ innocuous, but it is
bound to surprise someone eventually --- witness the message that started
this thread! Now you might argue that it was "just a bug" in some
package's postrm script or whatever. True, but: packaging is a
complicated process, and something similar is bound to occur again.
The real bug is the policy quoted above. The "/usr/local" hierarchy
should be understood to be just that: LOCAL. Nothing in Debian should
touch it. Ever.
I think the Debian policy ought to be changed.
In fact, the policy is a bit unclear or perhaps contradictory. Just above
policy section quoted above, we see:
3.1.1 Linux File system Structure
The location of all installed files and directories must comply
with the Linux File system Hierarchy Standard (FHS). The latest
version of this document can be found alongside this manual or on
http://www.pathname.com/fhs/.
Hmm. It says the *location* of directories must comply with FHS. Why
doesn't this read simply "The Debian file system must fully comply with
FHS"? Is it intended that Debian follow the FHS only in *location* but
not in *intent* or *use* of directories? For instance, FHS allows the
directory location /usr/lib. Can I ignore the *intent* of /usr/lib, and
put a user-executable binary in it? Or am I reading too much into this
bit of --- oddly-worded, to my eyes --- policy?
Well, let's assume that I'm reading too much into this, and that the
Policy writers really intended that Debian be fully FHS compliant.
Then the bit of Debian Policy about /usr/local contradicts the FHS section
found at http://www.pathname.com/fhs/2.0/fhs-4.6.html. Paraphrasing, this
page says that after a fresh install, this hiearchy may contain *empty*
subdirectories bin, games, include, lib, sbin, share, and src, and nothing
else.
I prefer the FHS way, and propose that Debian adopt it.
(Otherwise, I'll have to adopt /usr/local/really-local/{bin,lib,etc} as
the place for local stuff that Debian won't touch!)
Reply to: