Re: please unblock libpng 1.2.15~beta5-0
Le jeudi 14 décembre 2006 à 23:19 -0800, Steve Langasek a écrit :
> Unfortunately, 1.2.8 is not the version of libpng in testing today; 1.2.13
> is, and that version has *known* RC bugs.
> Moreover, there has now been a shlibs bump in this beta version (warranted
> or not, I don't know) that blocks a number of packages in unstable. So if
> there is a reason that 1.2.15beta5 is not releasable, we need to figure out
> how to get that reverted as well, from what I can see.
> After a quick review, the latest shlibs bump is definitely wrong. Actually,
> there are two symbols *missing* from 1.2.15beta5: png_read_destroy, and
> png_write_destroy. This is an ABI regression that needs to be resolved
> before .15 can be considered for etch.
> Anibal, both of these bugs (the gratuitous shlibs bump and the ABI
> regression) need to be fixed before this package can be considered for etch.
> The ABI change even seems to be a *Debian-specific* change between .13 and
> .15 as a result of you silently dropping part of the Debian diff, so there's
> no excuse for not fixing this.
> Correct shlibs for this library would appear to be
> libpng12 0 libpng12-0 (>= 1.2.13)
> udeb: libpng12 0 libpng12-0-udeb (>= 1.2.13)
> because I do see a new symbol added to the export table between 1.2.8 and
> I also see 130 symbols that have been *dropped* from the export table
> between 1.2.8 and 1.2.13! I'm not aware that this was ever discussed, and I
> have no idea how many of these were part of the exported API in 1.2.8. But
> seeing symbols with names like 'png_combine_row' going missing, I have grave
> misgivings about even 1.2.13 being included in etch.
Indeed, the two symbols that were added by removing the drop_pass_width
patch are in fact removed again, together with the 130 missing symbols.
My mistake for asking a shlibs bump to 1.2.13-4 while it was in fact
only needed for 1.2.13-0.
I agree with the rest of the reasoning, but this is even worse than what
you describe: those 130 symbols were removed because their ABI isn't
stable across minor libpng releases. Which means we can still add them
back, but this could trigger other bugs in software like optipng or
pngcrush, which actually make use of these symbols, as they could have
changed (or not) since 1.2.8.
The only sane solution if you want to get quickly to a releaseable state
is to go back to the last 1.2.8 package and to backport security fixes.
I've also explained more long-term solutions for the libpng madness on
my planet posting.
Josselin Mouette /\./\
"Do you have any more insane proposals for me?"