Re: please unblock libpng 1.2.15~beta5-0
* Steve Langasek (vorlon@debian.org) [061219 09:31]:
> On Mon, Dec 18, 2006 at 04:39:49PM +0100, Andreas Barth wrote:
> > 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.
These are:
png_get_int_32
png_get_uint_16
png_get_uint_31
png_get_uint_32
png_save_int_32
png_save_uint_16
png_save_uint_32
> > 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!)
Yes, we need to chek that. But this isn't an regression for the current
unstable version, so we could allow this version into etch.
> > 2 X+++++++++
>
> These are the only two symbols that would potentially be a reason to prefer
> .13 over .15.
Agreed. This are png_read_destroy and png_write_destroy. These packages
break:
Checking stable
found in pool/main/g/gimp/gimp_2.2.6-1sarge1_i386.deb: /usr/lib/gimp/2.0/plug-ins/png
found in pool/main/c/cupsys/libcupsimage2_1.1.23-10sarge1_i386.deb: /usr/lib/libcupsimage.so.2
found in pool/main/libt/libtk-img/libtk-img_1.3-13_i386.deb: /usr/lib/Img1.3/libpngtcl1.0.so
found in pool/main/d/drscheme/mzscheme_209-5_i386.deb: /usr/lib/plt/collects/plot/compiled/native/i386-linux/plplot-low-level.so
found in pool/main/p/pngmeta/pngmeta_1.11-3_i386.deb: /usr/bin/pngmeta
found in pool/main/q/qemacs/qemacs_0.3.1-5_i386.deb: /usr/bin/html2png
found in pool/main/v/vrweb/vrweb_1.5-11_i386.deb: /usr/bin/vrweb
Checking testing
found in pool/main/a/amsn/amsn_0.95+dfsg2-0.1_i386.deb: /usr/lib/amsn/utils/TkCximage/TkCximage.so
found in pool/main/d/drscheme/drscheme_352-6_i386.deb: /usr/lib/plt/collects/plot/compiled/native/i386-linux/libplplot.so
found in pool/main/libt/libtk-img/libtk-img_1.3-15_i386.deb: /usr/lib/Img1.3/libpngtcl1.0.so
found in pool/main/p/pngmeta/pngmeta_1.11-5_i386.deb: /usr/bin/pngmeta
found in pool/main/q/qemacs/qemacs_0.3.1.cvs.20050713-3_i386.deb: /usr/bin/html2png
found in pool/main/v/vrweb/vrweb_1.5-15.2_i386.deb: /usr/bin/vrweb
Checking unstable
found in pool/main/a/amaya/amaya_9.51-2.1_i386.deb: /usr/lib/amaya/wx/bin/amaya
found in pool/main/a/amaya/amaya_9.51-2.1_i386.deb: /usr/lib/amaya/wx/bin/print
found in pool/main/a/amsn/amsn_0.95+dfsg2-0.1_i386.deb: /usr/lib/amsn/utils/TkCximage/TkCximage.so
found in pool/main/d/drscheme/drscheme_352-9_i386.deb: /usr/lib/plt/collects/plot/compiled/native/i386-linux/libplplot.so
found in pool/main/libt/libtk-img/libtk-img_1.3-15_i386.deb: /usr/lib/Img1.3/libpngtcl1.0.so
found in pool/main/p/pngmeta/pngmeta_1.11-5_i386.deb: /usr/bin/pngmeta
found in pool/main/v/vrweb/vrweb_1.5-15.2_i386.deb: /usr/bin/vrweb
> > 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.
I guess so, yes. Though it would be better if upstream would start
getting any clue about how libraries work.
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
Reply to: