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. 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. We will probably need to keep a libjpeg62 around in squeeze btw, as it's likely that some external stuff will require it... -- ·O· Pierre Habouzit ··O madcoder@debian.org OOO http://www.madism.org
Attachment:
signature.asc
Description: Digital signature