Hi, xft upstream stopped exporting a bunch of internal symbols in 2.1.9 [1], which strictly speaking means we should have to bump the ABI. libxft2 had 307 reverse-dependencies in sid/main/i386 last I checked, though, so transitioning to libxft3 doesn't seem like something we really want to do. So I checked all reverse dependencies in sid/main/ia64 on merkel, and it seems that none of them use any of the removed symbols. Upstream didn't bump the ABI either, so I guess they're pretty confident these symbols aren't being used anywhere. libXft 2.1.9 was released in June last year, one symbol was reexported in 2.1.12 in December [1], and the upstream bugzilla doesn't seem to mention further breakage, so it seems to me that upgrading to 2.1.12 should be safe. I wanted to check with the release team first, though, and have your opinion on whether we should go ahead with the new upstream (after etch is out, of course), by: - bumping the ABI and deal with the transition with aggressive binNMUing, - uploading xft 2.1.12 as-is, with the symbols dropped, hoping for the best, and possibly readding some symbols individually if there's some breakage, - or reverting the unexporting of the internal xft symbols. Thanks, Julien [0] http://git.debian.org/?p=pkg-xorg/lib/xft.git;a=commitdiff;h=824f87ba102e36808c59e92d7f527ca2f8b00026 [1] http://git.debian.org/?p=pkg-xorg/lib/xft.git;a=commitdiff;h=22112a0ee3bd16b40e414bac32c532a73cbabbcb
Attachment:
pgpS8gz4NmQi0.pgp
Description: PGP signature