Things aren’t exactly going as smoothly as expected. Here are some explanations.

First collateral damage: non-free fglrx and nvidia drivers.

We have to admit we didn’t think of those when we moved libGL.so.1 (and friends) from /usr/lib to /usr/lib/<triplet> (that’s the move we call “adding multiarch support”). In the mesa 7.10.3-2 upload, some Breaks statements were added to prevent users from installing new mesa packages if they still have old (without multiarch support) fglrx or nvidia packages.

Solution: Sticking to the mesa packages in testing is the way to go until fixed fglrx and nvidia packages are uploaded.

Second collateral damage: xserver-xorg-core in testing.

The plan was to rebuild the server in unstable against the new mesa libraries, so that it would look into the new /usr/lib/<triplet> directory for mesa drivers. Since no source changes were needed, we went for a binNMU as explained in the previous blog post.

That’s the usual way to deal with libraries, and does the job very nicely. But that failed in this special case, for the following reasons:

1. The server only has libgl1-mesa-dri in Recommends, so there’s no hard dependency here.
2. Usually, rebuilding a package against a new library means getting a dependency on the new library (typically because the binary compatibility has been broken, so the SONAME got bumped, meaning one depends on libfoo42 instead of libfoo41). And that means going in testing at the same time as the new library.

But in this case, rebuilding against the new library just means having a different search path somewhere in libglx.so. So the rebuilt package (2:1.10.2-1+b1) happily reached testing, which still contains the old mesa packages, which ship their files in the old /usr/lib path!

Solution: Stick to 2:1.10.2-1 packages (snapshot.debian.org to the rescue), or wait a bit and get fixed packages.

To get fixed packages, two things were needed:

1. Getting the server package fixed in unstable: that means adding Breaks against old (pre-multiarch) mesa packages, as seen in 2:1.10.2-2. This will ensure that new server package built against new mesa will not be co-installable with old mesa packages, and both mesa and the server should migrate together to testing.
2. Getting the server built again within testing, so that it gets built against old mesa, so that both mesa and the server in testing remains without multiarch until the packages in unstable are ready to migrate together.

While taking care of that second step, it was discovered that many buildds are still lacking a testing chroot, so there might be some delay until the server is rebuilt in testing (as 2:1.10.2-1+wheezy1). Eager users can use the time travel machine mentioned above to get stuff working again sooner.

(As far as I can tell, the last problematic combination which would remain would be 2:1.10.2-1+wheezy1 server with new mesa, but we’ll make sure we update the Breaks in the new mesa to make sure that it can’t happen. Since it’s not as urgent as getting the server in testing fixed, it’s only queued for mesa 7.10.3-3 for now.)