* Steve Langasek ([EMAIL PROTECTED]) [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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
