Bug#362885: x11-common: unable to upgrade, rmdir: /usr/X11R6/bin: Directory not empty
#include <hallo.h>
* Steve Langasek [Mon, Apr 17 2006, 08:58:38PM]:
> On Mon, Apr 17, 2006 at 09:51:58AM +0200, Eduard Bloch wrote:
> > #include <hallo.h>
> > * Steve Langasek [Sun, Apr 16 2006, 04:58:25PM]:
>
> > > If you ask me, I think it's better to keep the vast majority of irritating
> > > bugs confined to unstable, and only make users of stable deal with the
> > > single issue of moving their files out of /usr/X11R6/bin; which is why I
> > > asked David to implement this transition when it became clear that things
> > > were breaking because of the move to /usr/bin.
>
> > I agree with most of your arguments, especially because our default bash
> > PATH is still pointing to /usr/X11R6/bin, but there is one thing which I
> > actually reported... if there is cruft remaining in the directory, the
> > whole upgrade should _not_ break.
>
> > Implementing an unsafe single "rmdir" and hope that it won't
> > fail is IMO not a proper solution. If the directory must be moved out
> > of the way, then it should be renamed. Or the old contents need to be
> > moved to the new location, possible correcting symlinks
>
> Er, any number of these files may belong to other Debian packages that we
> don't conflict with (because we didn't know about them). Why would it be ok
> for a package to mangle files belonging to other packages in this fashion?
Okay...
> If you move the files, dpkg may be unable to find them at package
> uninstallation, resulting in orphaned files on the filesystem; or there may
Not 100% correct. The problem of deinstallation is covered with the
symlink workaround since dpkg AFAICS follows the symlinks in the path
when removing a file.
It's only the other way round that does create headaches, future
installations of third-party packages which may try to install files
into X11R6/bin and may overwrite files from other packages. I thought
a while about that and could not come up with any sane solution, not
even hacking dpkg's .list files would help because of missing
information. Only blacklisting this directory in dpkg would have been a
"good" solution but it's too late for that.
> Forcing the user to deal with the conflict is the only safe way of handling
> files left in /usr/X11R6/bin. It should probably be turned into a debconf
> note later on, but for the time being I think the current behavior is as
> good as it's going to get.
"safe" does not mean reliable or usefriendly. I still think that the
current lone "rmdir" hidden in the postinst is not sufficient. What we
need is IMO a list of "dirty" files - files that have existed in Debian
in X11R6/bin directory before and which would certainly be uninstalled
by apt/dpkg during the upgrade. The debconf's config script should be
executed during dpkg-preconfigure (NOTE: not in the middle of upgrade!),
scan the existing /usr/X11R6/bin directory, substract the set of "dirty"
files and if there are still remaining files in the list, then the user
should be given a chance to abort the whole installation before it
starts. And a list of remaining files should be printed. Maybe together
with 3rd-party packages that those files may belong to.
If you wish me to implement a such solution, please say "do it" and I
will try to.
Eduard.
Reply to: