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.
Cheers
Luk
Reply to: