Bug#371874: x11-common postinst error: trouble with /usr/include/X11
On Wed, Jun 07, 2006 at 10:48:44PM -0400, Joey Hess wrote:
> hendrik@topoi.pooq.com wrote:
> > Package: x11-common
> > Version: 1:7.0.20
> > Severity: grave
> > X-Debbugs-CC: "Henk Boom" <lcpublic@gmail.com>
> >
> >
> > 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
Reply to: