Re: libxft for lenny

2007-02-11 Thread Steve Langasek
On Sun, Feb 11, 2007 at 02:36:30AM +0100, Julien Cristau wrote:
 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.

Were any of these symbols ever exposed in the published headers?  If not,
then I think it's pretty clear-cut that the symbols are internal and can be
safely dropped without worrying about ABI breakage.

If some of these symbols were exposed in the headers, it's less clear; even
if no Debian packages use them, there could still be third-party software
that does, so bumping the soname is still the right thing to do.  But
there's sure to be resistance upstream from those indoctrinated into the Red
Hat school of library management, as there was for freetype, so the path of
least resistance would probably be to leave the soname alone, hoping for
the best.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: libxft for lenny

2007-02-11 Thread Julien Cristau
On Sun, Feb 11, 2007 at 13:34:49 -0800, Steve Langasek wrote:

 Were any of these symbols ever exposed in the published headers?  If not,
 then I think it's pretty clear-cut that the symbols are internal and can be
 safely dropped without worrying about ABI breakage.
 
As far as I can see, they were never exposed in X11/Xft/Xft{,Compat}.h.
I guess that means we don't have to worry about this.  Sorry for not
having checked that first, and thanks for your reply.

Cheers,
Julien


pgp9ZFkSUaT6l.pgp
Description: PGP signature


libxft for lenny

2007-02-10 Thread Julien Cristau
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


pgpG8BFNcScLv.pgp
Description: PGP signature