*sigh* I meant this to go to policy, but I wasn't careful with my keypresses in gnus...
Martin Schulze <[EMAIL PROTECTED]> 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.
