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
(and friends) from
/usr/lib/<triplet> (that’s the move
we call “adding multiarch support”). In the
mesa 7.10.3-2 upload,
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:
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:
- The server only has
Recommends, so there’s no hard dependency here.
- 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
libfoo41). And that means going in
testingat 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
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:
- Getting the server package fixed in
unstable: that means adding
Breaksagainst 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
- Getting the server built again within testing, so that it gets
built against old mesa, so that both mesa and the server in
testingremains without multiarch until the packages in
unstableare 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
fixed, it’s only
queued for mesa 7.10.3-3