Re: libjpegv7 transition
Bill Allombert wrote:
> 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.
>>>> 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).
Are bugs for these filed already to have them build depend on libjpeg-dev?
>>>> 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...
Do you know examples of these?
> 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?
Please upload to experimental so we get an idea on the possible impact
and have it NEW processed etc, TIA.