x11-common preinst script fails (was: aborts /usr/X11R6/bin not empty)

My apologies, I forgot to mention that the error happened while updating from dapper to the edgy pre release.

I remove the update-manager task because there is little that the update-manager can do to fix this problem (other than report it).

Looking into x11-common.preinst it looks like this is the fragment that causes the trouble:

  # We need to remove /usr/X11R6/bin so we can replace it with a symlink
  if [ -d "/usr/X11R6/bin" ] && [ ! -L /usr/X11R6/bin ]; then
    if ! rmdir "/usr/X11R6/bin"; then
      run db_fset x11-common/x11r6_bin_not_empty seen false
      run db_input critical x11-common/x11r6_bin_not_empty
      run db_go
      exit 1
    fi
  fi

I don't think it should fail but issue a message and move the old dir aside to prevent upgrades from failing.

Cheers,
 Michael

It looks like opera is responsible for a large percentage of these failures, see also bug #68983.

This is still a problem with the upgrade from edgy.
perhaps a warning should be made for those upgrading based on wiki instructions.

Here are the log files from the upgrade attempt in the hope that they may help.

Upgrading from Dapper to Edgy is prevented by any package which has stuff in /usr/X11R6/bin in Dapper.

IMHO there should be an update to Edgy where x11-common is marked as being in conflict with the Dapper version of all offending packages. Any chance to implement that?

See also bug #70382 and bug #71915 ... I'm sure there must be lots more.

Actually, since you can't know which packages in multiverse and what not might still have spurious files in /usr/X11R6/bin it's probably better to go with the suggestion in comment #6 https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/67996/comments/6

In other words, installation should not fail; either a warning should be generated and the offending files listed (this would have helped people immensely in debugging this problem!) or perhaps they should even be moved elsewhere, as Michael suggested (but then that is a policy violation too, isn't it?).

Then the user can remove offending packages as they see fit, and the preinst can remove /usr/X11R6/bin at a later date when it is finally empty, whenever x11-common is upgraded again.

Is this good enough for a SRU proposal for Edgy?

This bug broke my upgrade today. It really should move the old bin/ aside if not empty, instead of failing. Aborted dist-upgrades are bad.

What happened today was:

  - I changed apt/sources.list to point to a new release.
  - I ran "apt-get dist-upgrade", and apt happily started making changes.
  - x11-common failed, so apt aborted.
  - I manually resolved the error (remove everything from /usr/X11R6/bin)

At this point, apt could not continue its dist-upgrade. Apt could only "apt-get -f install", which meant removing several hundred packages.

So, I spent the rest of the day recovering.

upgrading to gutsy I get the error message "update manager" failed to install or upgrade. fatal IO error 9 (bad file descriptor) on X server: 0.0.
I then get the message-
the upgrade aborts now. Your system could be in an unstable state. A recovery will now run now. (dpkg --configure -a)

apt.log and term.log attached.

Pretty please, what needs to happen in order for upgrades from Dapper to be fixed? There are a couple of viable proposals above, but they need to happen before it's too late for Hardy.

What apps are there that still install stuff in /usr/X11R6/bin? x11-common conflicts with a _lot_ of packages (also 3rd party) that have used that directory, so the list could be extended.

era: you mentioned that xli is one example of an offending package. It has been fixed long ago, so have you actually tried to upgrade dapper -> hardy?

On Thu, 28 Feb 2008 10:55:11 -0000, "Timo Aaltonen"
<email address hidden> said:
> era: you mentioned that xli is one example of an offending package. It
> has been fixed long ago, so have you actually tried to upgrade dapper
> -> hardy?

Nope, I have not. The systems I have are Gutsy or lower, and IIRC I had
to remove xli in order to get upgrades from Dapper working.

/* era */

--
If this were a real .signature, it would suck less. Well, maybe not.

Alright, in that case I'll mark this fixed. The problem that billmac had is not related.

Listing every conceivable package as a conflict is probably not a good solution. Conflicting explicitly with known 3rd-party packages seems kludgy at best. It would be safer to assume there are unaccounted files in /usr/X11R6/bin, because users are unpredictable and do strange things.

In that case, how about changing the install script to move the contents of the directory, if any, before removing it and symlinking it to ../bin? Or, handling a failed rmdir by asking the user to manually resolve the issue, instead of just bailing?

I doubt the results will be perfect, but if I have to choose between a slightly broken system (custom add-ons broken) or a mostly-broken system (half of the packages removed, requiring hours of manual recovery), I'd choose the slight breakage.