xserver-xorg-input being removed on upgrade

Hi rsemenov,

Please attach the output of `lspci -vvnn`, and attach your /var/log/Xorg.0.log file from after reproducing this issue. If you've made any customizations to your /etc/X11/xorg.conf please attach that as well.

The problem is that xserver-xorg depends on xserver-xorg-input-all or xserver-xorg-input-2.1. xserver-xorg-input-2.1 is a virtual package being provided by the individual input drivers (or 32 of them anyway). So it is possible for all but one of the drivers to be removed, which could render the system useless.

Debian's xserver-xorg-input-2.1 is provided by only 4 packages.

I had this problem as well. I suspect it is more of an issue with dist-upgrade than xorg itself. I have since resolved the issue. It occurred in the same upgrade to xinput 1.3.0-1ubuntu3, which I think may have caused the problem with the dist-upgrade.

As Bruce Cowan mentioned, the problem is that xserver-xorg depends on xserver-xorg-input-all | xserver-xorg-input-2.1 , and the dist upgrade decided to remove xserver-xorg-input-all , -evdev and -synaptics. Because other installed packages still provided xserver-xorg-input-2.1 (eg. -wacom), dependency checking worked out ok, while removing the critical -evdev package.

Installing xserver-xorg-input-all again resolved the problem.

Bumping importance - it seems a lot of people are hitting this - on IRC as well.

The problem is that users don't bother to notice when a dist-upgrade is going to remove most of GNOME. That's not a bug.

Just adding to what has already been said:
This happens when upgraded sets of packages is only partially uploaded to the repos, and also, there is a "breaks" directive in the package itself. Since the new packages declare that the old packages will be broken by installing the new packages, the package manager contemplates removing that old package.

In this case, the culprit package was xserver-xorg-core. It declared that it breaks xserver-xorg-evdev (under a certain version and the updated version hadn't been released), and thats where the trouble starts. From what Hew McLachlan wrote, it looks like having evdev removed caused xserver-xorg-input-all to be removed, and that was ok, because there were packages that provided xserver-xorg-input-2.1

We can't just prevent packages from being removed. At some point responsibility needs to be on the user.

All of the current xserver-xorg-input-* packages provide xserver-xorg-input-2.1. I appreciate the general problem, but is it still an issue in practice for Ubuntu 8.10? (It's currently a release-critical bug for 8.10.)

I can confirm this. My keyboard and mouse work on the LiveCD and the Grub menu and recovery root shell, but not in gnome. I will try installing gnome to fix this problem, will report back.

I cannot confirm the workaround because my school requires a proxy connection to the internet, and I'm not sure how to do it by shell.

This may be caused by having a wireless-keyboard/mouse

I think the other part of the issue we're missing is that the installer hangs on cleaning up portion of the install. I can confirm all of these problems when upgrading from 8.04 to the beta. sadly, it breaks all of the terminal hotkeys as well - turns the screen into seemingly random flashing ASCII Characters.
Also noticed that xinput was held back from being installed on the upgrade. Any chance this is related? That isn't a part of xserver-xorg-xinput-all is it?

schmoo2x: The cleaning up freeze sounds like bug 280236, which as been fixed. You said you are upgrading to Intrepid beta; please make sure you are upgrading to the latest version of Intrepid from the repositories.

I haven't had this problem since the bug was reported. I suspect it's only a problem for upgrades from Intrepid, but Hardy upgrades should still be checked for this bug.

Hew: I get this bug while upgrading to intrepid from hardy.

I'm dropping the release-critical task for this. While it's certainly true that this removal can occur, that happens only when things are in flux for brief periods during development. That's not an issue currently, and won't affect the release. Also, it's sort of an outcome of how the infrastructure works, not an xorg bug in particular, so may be worth refiling to a different package, although I'm not sure what.

This is basically fixed for good, because xserver-xorg depends on -evdev as well as on -input-all. So it should not be possible to get in the situation where -evdev would be removed. Not without force anyway...