On Mon, Dec 18, 2006 at 04:39:49PM +0100, Andreas Barth wrote:
> * Andreas Barth ([EMAIL PROTECTED]) [061216 22:20]:
> > I'll update this as soon as we have more information (and I would also
> > like to check the symbol lists before an upload - I'm working on this
> > right now).
> Ok, more updates: The exported versions look way worse than I hoped. We
> have (looking at 1.2.8rel-1, 1.2.8rel-2, 1.2.8rel-3, 1.2.8rel-4,
> 1.2.8rel-5.1, 1.2.8rel-5.2, 1.2.8rel-6, 1.2.8rel-7, 1.2.13-4,
> 1.2.15~beta5-0, sorted from left to right, whereas 1.2.8rel-1 is in
> sarge) the following numbers of how often symbols were exported and not:
> 191 X++++++++++
These are no problem, of course.
> 125 X+
I would say these aren't a problem either, at least to such an extent that
we would want to revert them; they've been gone from unstable since
September 2005 without major incident. We should probably identify any
packages in sarge that reference them and make sure libpng12-0 has versioned
conflicts on them?
> 7 X+ ++
These may or may not be a problem depending on whether the ABI has changed
between the versions exported in 1.2.8 and 1.2.13/15. We should probably
look at these individually.
> 1 X ++
There are an issue for shlibs only. (Assuming they're meant to be exported
and shouldn't be suppressed to keep people from using them!)
> 2 X+++++++++
These are the only two symbols that would potentially be a reason to prefer
.13 over .15.
> 6 X+ +++++
And from Joss's mail:
* the 6 symbols that were removed in 1.2.8rel-2 and added back in
1.2.8rel-4 are part of the so-called "internal" libpng API, used
by broken software like OptiPNG and pngcrush; I've added them
back to keep backwards compatibility, and upstream developers of
these software are considering to ship private copies of these
functions (no, I don't want to argue which of these evils is the
worst); this is why upstream doesn't ship them anymore in the
latest version;
So given that upstream doesn't actually change the soname any time they
*should* do so :P, we are probably better off in the long term if we go
ahead with dropping these as has been done upstream, and force the packages
using them to be fixed.
That gives us:
- 125+6 symbols whose use in sarge should result in a versioned conflict in
etch
- 7 re-introduced symbols in 1.2.13 whose ABI needs to be checked
- 2 symbols that may be a reason to revert to 1.2.13 if the packages using
them aren't covered by either of the above
Does this sound right?
--
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]
