On Wed, Jun 07, 2006 at 10:48:44PM -0400, Joey Hess wrote: > [EMAIL PROTECTED] wrote: > > Package: x11-common > > Version: 1:7.0.20 > > Severity: grave > > X-Debbugs-CC: "Henk Boom" <[EMAIL PROTECTED]> > > > > > > x11-common postinst error: trouble with /usr/include/X11 > > > > > > We get this problem on two different systems -- an etch AMD-64 (installed > > as Debian-AMD64, but upgraded as Debian since a few weeks ago), and etch > > running on a 32-bit Athlon (installed as sarge, subsequently dist-upgraded > > to etch). > > > > We are trying to upgrade our machines from xorg 6.9 to xorg 7.0, and have > > been stymied by the installation behaviour of x11-common, specifically the > > one that appears as /var/cache/apt/archives/x11-common_1%3a7.0.20_amd64.deb > > on the AMD64, and /var/cache/apt/archives/x11-common_1%3a7.0.20_i386.deb > > on the 32-bit system. > > > > The post-install script complains that the symbolic link /usr/include/X11 > > does not exist. > > > > On the AMD-64 we managed to get past this point, but we're not sure exactly > > what we did that did the trick. We tried uninstalling x11-common in order > > to install it again. Forcing uninstallation and installation did not *seem* > > to work, but we are not familiar enough with the behavious of apt-get to > > know > > this for sure. We succeeded on tha AMD-64 only after deleting about a > > hundred packages that directly or indirectly depended on x11-common, then > > uninstalling and reinstalling it. > > > > On the 32-bit machine we are utterly at a standstill, since there are > > far, far too many packages to delete by hand. > > > > In case it's relevant, both machines use nvidia drivers built from the > > Debian nveidia-kernel-source package. > > > > On the 32-bit machine, we took inspiration from someone's advice on the > > net, and tried creating the /usr/include/X11 directory ourselves, since > > although x11-common complains about a missing symbolic link, it is > > apparently > > supposed to end up with a directory. But in this case it complains that > > /usr/include/X11 is not a symbolic link. > > > > If we re-create the symbolic link as it appears on other systems still > > using 6.9, it reports that the symbolic link does not exist, and when we > > check afterwards, the symbolic link has disappeared. > > I ran into this same sort of insanity today with the package. I was > finally able to get past it by: > > * Creating /usr/lib/X11 -> ../X11R6/lib/X11 > * Creating /usr/include/X11 -> ../X11R6/include/X11 > * Making sure that there was no reason for it to complain about > /usr/X11R6/bin, by a) removing or upgrading any package that installed > a file there and b) after all such packages were removed/upgraded, > moving any other files out of that directory. > * Finally, apt-get install xorg-common again. > > My bug reports (#371152 and #371161) have some more detail about why > it's breaking (and how it handles any breakage by hosing the system so > it can't be recovered except through the manual steps above) and transcripts > of some of what happens when trying to upgrade it.
Ok, this is an extremely troubling bug. The previous x11-common's postinst gets called when the new x11-common's postinst fails with the /usr/bin/X11 switch. At this point, x11-common isn't shipping those symlinks and the previous x11-common's postinst fails because it requires that they're there. I'm not sure how we get to this situation to begin with, because in my own tests with upgrading x11-common with the /usr/bin/X11 error condition, I didn't hit this bug, so I'm not 100% sure I understand it fully. Now, the way around this that I can see is that the new postinst needs to manually re-create the symlinks prior to exiting during the error condition. This will allow the old version's postinst to complete properly. However, this creates a situation where we need to manually remove those symlinks later, causing more opportunities for problems. I'm trying to come up with a better way to do this, but I can't right now. Would someone be able and willing to test a fix if I can come up with one? - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
