Re: /usr/local in some packages
*sigh* I meant this to go to policy, but I wasn't careful with my
keypresses in gnus...
Martin Schulze <joey@tapiola.Infodrom.North.DE> writes:
> Joseph Carter wrote:
> > On Tue, Sep 29, 1998 at 12:16:52PM +1000, Herbert Xu wrote:
> > > After purging emacs today, the damn thing deleted my /usr/local symlink since
> > > it was the last package to have /usr/local in it. Obviously this is not very
> > > clever.
> > >
> > > So we should either remove /usr/local from all packages, or tell dpkg to not
> > > remove /usr/local. I personally favour the former solution.
> >
> > /usr/local should not be used in packages. Thought that was already policy?
>
> Right. No package may install stuff in /usr/local nor in /opt. Period.
>
> I guess the only exceptions are perl and emacs where the package
> should create the directory structure so people won't have to
> guess them.
I'm very glad TeX set up its /usr/local directory structure; that I
_really_ would not want to guess at. In fact, anything else that
requires directories in /usr/local should set up the structure; the
only problem I see is that people may (rightly) wish to mount
/usr/local read-only, in which case installation of packages that
create /usr/local directory structures may fail.
One solution:
Packages may place only directories in /usr/local - furthermore,
base-files should have the /usr/local directory in it. This would
prevent the problem that started this thread, as /usr/local wouldn't
get removed (since removing base-files is, uh... "highly
undesireable").
Another solution:
Packages may not contain any /usr/local directory structure, but may
create it in postinst. If so, they must remove it in (pre|post)rm.
Something like this: (for emacs)
#in postinst
set +e
mkdir -p /usr/local/lib/emacs/site-lisp/
set -e
#in prerm
set +e
rmdir -p /usr/local/lib/emacs/site-lisp/ /usr/local/lib/emacs/
set -e
The problem with this is that this is a lot less uniform than relying
on dpkg to fill in/remove the directories, and I can see some packager
screwing it up, especially if it's not explicit policy. Also, what do
you do when a given /usr/local directory may be used by several
packages? My guess is that all should try to create it, but removal
should be left to the local sysadmin. (for example, emacs creates
/usr/local/lib if necessary, but doesn't try to delete it) As an
exception, if a given package conflicts with something else that uses
a certain directory, then it may delete it upon removal. (for
example, xemacs also uses /usr/local/lib/emacs/site-lisp) Ugh. This
is getting too messy.
Yet Another Solution:
Just like "One Solution" above, except that dpkg should be modified so
that it doesn't take failures in /usr/local seriously. (that is, it
continues installation). This has the advantage that it requires
almost no changes in the many packages that create /usr/local
directory structures (just a minor tweak to basefiles to include
/usr/local); furthermore, dpkg is allowed to keep track of which
directories belong to which packages, so the issue of when to remove a
directory is clear. For non-free packages like Qt which need to
install files into /usr/local for silly non-free legal reasons, the
preinst could attempt a:
set +e
mkdir -p /usr/local/lib/qt/
touch /usr/local/lib/qt/.test
rm -f /usr/local/lib/qt/.test
This will bomb out if /usr/local is read-only, and succeed if not.
While this won't cover every case, (say, /usr/local read-only and
mounted across many machines) I don't see covering every case as too
difficult a task.
This last solution seems the cleanest, and at the same time the
easiest to implement. I like it when things work out that way.
Reply to: