[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: BinNMU for libjpeg8 transition

Bill Allombert wrote:
> On Thu, Feb 11, 2010 at 08:00:18PM +0100, Luk Claes wrote:
>> Sven Joachim wrote:
>>> On 2010-02-11 19:38 +0100, Luk Claes wrote:
>>>> Bill Allombert wrote:
>>>>> libjpeg62-dev need to be kept for LSB compatibility.
>>>> Can you point me to the section that points to that need?
>>> http://refspecs.freestandards.org/LSB_3.2.0/LSB-Desktop-generic/LSB-Desktop-generic/libjpeg62.html#LIBJPEG
>>> It's the same in LSB 4.0.
>> So libjpeg62 has to be remained, though libjpeg62-dev does not have to
>> stay and could be provided by libjpeg8-dev like I proposed from the start.
> libjpeg62-dev have to stay for *building* LSB package. 

Right, though if you want to have that, you should have been clear from
the start.

> But anyway this whole discussion is a distraction. The only real issue is
> whether we transition all package build-depending on libjpeg*-dev at once, or
> whether we transition first the one that build-depend on libjpeg-dev.

Nope, the real issue is that you apparently want to do a messy
transition even when the Release Team wants to avoid that.

> In the first case, I rename the current libjpeg62-dev to libjpeg6b-dev and 
> change libjpeg8-dev to provide libjpeg62-dev and conflict with libjpeg6b-dev.
> In the second case, we have to fix all packages that _Depends_ on 
> libjpeg62-dev to depend on libjpeg-dev instead.
> Following the instructions given in 
> <http://lists.debian.org/debian-release/2009/09/msg00216.html>
> I implemented the second solution, but I have no objection with
> implementing the first one if the release team change its mind.

Noone is changing their mind, though instead of a normal transition you
want to include a non coinstallable extra development package which is a
complete mess. Renaming even more packages is not going to make it any
less a mess.

The choice is either to make sure we have coinstallability or to drop
one development package IMHO.



Reply to: