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

Bug#892505: transition: openexr



Control: tags -1 confirmed

On 10/03/18 20:20, Matteo F. Vescovi wrote:
> Hi!
> 
> On 2018-03-10 at 16:35 (+0100), Emilio Pozuelo Monfort wrote:
> 
> [...]
> 
>>> while vips on some weird missing dependencies where openexr is not
>>> involved, it seems.
>>
>> Can you file a bug for this?
> 
> Gonna do it asap.
> 
>> BTW I see in your changelog:
>>
>> openexr (2.2.1-2) experimental; urgency=medium
>>
>>   * debian/: SONAME bump 22 -> 23
>>   * debian/control: add Breaks and Replaces for library replacement
>>
>> So IIUC, you upgraded 2.2.1-1, which bumped the SONAME, without bumping the
>> binary package name. Then you uploaded 2.2.1-2 with updated package name for the
>> bumped SONAME. However since both libopenexr22_2.2.1-1 and libopenexr23_2.2.1-2
>> ship libopenexr.so.23, you had to add some Breaks/Replaces. But you added:
>>
>> Package: libopenexr23
>> Version: 2.2.1-2
>> Replaces: libopenexr22 (<< 2.2.1-2)
>> Breaks: libopenexr22 (<< 2.2.1-2)
>>
>> That's unnecessarily broad, as it breaks against libopenexr22_2.2.0-11.1 that we
>> have in testing, when it shouldn't. That will cause pain during the transition.
>> Can you instead update the Breaks/Replaces to something like
>>
>>   libopenexr22 (= 2.2.1-1)
>>
>> or
>>
>>   libopenexr22 (>= 2.2.1)
>>
>> That should still conflict against the bad versions but not against the good ones.
>>
>> Basically if you can install libopenexr22/testing with libopenexr23, then we're
>> good to go.
> 
> That's what I've done now: I've just uploaded -3 revision that fixes the
> Breaks/Replaces with the first option you provided. And I've tested the
> co-installability of libopenexr22 from testing and libopenexr23 from
> experimental.

Good, that means this can be a 'smooth' transition, i.e. the new library package
can migrate while keeping the old one in testing at the same time, so the two
packages that fail to build are not really blockers (they are in order to finish
the transition, but they are not in order to move the rest of the packages to
testing). Thus please go ahead.

Cheers,
Emilio


Reply to: