Re: Name clash in prospective package
Lars Wirzenius writes ("Re: Name clash in prospective package "):
...
> For instance, there's no guarantee that /usr/local/lib exists, or that
> the admin wants it to exist, or that it won't cause any trouble if it
> does exist. I can't think of anything that would break, but admins
> are allowed to do funny things in /usr/local.
The problem with this strict approach is that we want (for obvious
reasons) our tools to search local directories too when looking for
commands, Perl modules, lisp files or whatever. Therefore we can't
avoid making some assumptions about what's in /usr/local.
The point of not putting things in /usr/local isn't, as I see it, so
that the sysadmin can put a baroque thing there and have everything
work - it won't - but so that they can put their own software there
(installed well or badly) without fear of it being destroyed by the
packaging system.
...
> I quite agree that it should be easy to set up such complex things
> [like directory structures &c in /usr/local], but not without asking.
I don't think we need to bother the user with one more question, if we
provide a way for an expert to have us leave /usr/local alone.
I propose the following resolution:
* A policy that packages should include in their .deb files empty
directories for path-searched directories. Files are not allowed, and
packages aren't allowed to touch /usr/local at all in their maintainer
scripts.
* When dpkg has the `ignore files matching pattern' option (this will
be read from a configuration file) you'll be able to stop it
installing things in /usr/local at all. I'm afraid this will be a
while coming, but in principle it's not too hard.
Ian.
Reply to: