On Sun, Jun 14, 2009 at 09:30:33PM +0200, Pierre Habouzit wrote: > On Sun, Jun 14, 2009 at 08:22:04PM +0100, Jurij Smakov wrote: > > On Sun, Jun 14, 2009 at 07:30:17PM +0200, Pierre Habouzit wrote: > > > On Sun, Jun 14, 2009 at 03:48:28PM +0200, Bill Allombert wrote: > > > > Dear release team, > > > > > > > > libjpeg v7 is likely to be released at the end of June. > > > > A prerelease tarball is available. > > > > > > > > This version is ABI-incompatible with libjpeg6b. > > > > However it should be fully API compatible. > > > > To avoid symbol conflicts with libjpeg v6, the symbols are versionned.. > > > > > > > > This means the transition should be relatively safe but will involve > > > > a lot of packages. > > > > > > > > How do you want me to proceed ? > > > > > > Unless I'm mistaken, those packages only build-depends on libjpeg-dev: > > > Package: analog > > > Package: blender > > > Package: dcraw > > > Package: exactimage > > > Package: fbi > > > Package: ffmpegthumbnailer > > > Package: fgfs-atlas > > > Package: freej > > > Package: fsviewer > > > Package: ghostscript > > > Package: gnash > > > Package: grace > > > Package: grace6 > > > Package: hasciicam > > > Package: htmldoc > > > Package: igstk > > > Package: inventor > > > Package: mathgl > > > Package: nxcomp > > > Package: openscenegraph > > > Package: pike7.6 > > > Package: poppler > > > Package: prima > > > Package: shoes > > > Package: ssystem > > > Package: steghide > > > Package: tipptrainer > > > Package: xen-3 > > > Package: xen-unstable > > > Package: xjig > > > Package: xnc > > > > > > Those build-depend on libjpeg62-dev | libjpeg-dev: > > > Package: csmash > > > Package: djvulibre > > > Package: epm > > > Package: flightgear > > > Package: iceape > > > Package: libmng > > > Package: metapixel > > > Package: simgear > > > Package: uvccapture > > > Package: wine > > > Package: xmhtml > > > Package: ygraph > > > > > > And a vast majority of packages build-depend on libjpeg62-dev (that is > > > roughly 220 packages if I'm correct). > > > > > > IOW, I'd say, first you can upload a new libjpeg in a new source > > > package, that doesn't provide libjpeg-dev for now, so that we can clear > > > NEW and FTBFS-es and stuff like that. > > > > I have little experience in stuff like this but as the new libjpeg is > > fully API compatible, couldn't the new dev package just have > > 'Provides: libjpeg62-dev'? Then it should still be possible to do binNMUs > > without requiring sourceful uploads of all packages build-depending on > > it. The bugs to switch to libjpeg-dev as build-dep would still need to > > be filed, but they could be wishlist. > > > > AFAIK, that's how the transition from libltdl3 to libltdl7 was handled. > > It could work, though doing it one step at a time is probably wise. I > expect far more problems with libjpeg than with libltdl, but I may be > wrong and I'm just paranoid. Given the history of the code I am confident breakage will be minimal. (looks for the latest DSA on libjpeg). > And FWIW, breaking something like 10 years of binary compatibility, when > the glibc provides all you need to deal with symbol versioning, and > you're as pervasive as libjpeg, is hell. I suppose it can be safely argued that breaking binary compatibility once in ten years is better than breaking them every years. > We will probably need to keep a libjpeg62 around in squeeze btw, as it's > likely that some external stuff will require it... That makes sense. In anycase, libjpeg7 has been released now and is ABI incompatible with libjpeg6b (and carry a new soname and is versionned). What do you want me to do at this point? Cheers, -- Bill. <ballombe@debian.org> Imagine a large red swirl here.
Attachment:
signature.asc
Description: Digital signature