Bug#892505: transition: openexr

[Emilio Pozuelo Monfort <pochu@debian.org>]

On 10/03/18 16:05, Matteo F. Vescovi wrote:
> Hi Emilio!
> 
> On 2018-03-10 at 10:27 (+0100), Emilio Pozuelo Monfort wrote:
> 
> [...]
> 
>>> ### Dependency level 3 ###
>>>  * gmic_1.7.9+zart-4 => FTBFS (not openexr related)
>>>  * gst-plugins-bad1.0_1.8.3-1 => FTBFS (not openexr related)
>>
>> unstable has gst-plugins-bad1.0 1.12.4-2.
>> Did you really check with 1.8.3-1?
> 
> Gosh, reverse-depends from ubuntu-dev-tools package brought that version
> in my list, no idea why. Anyway, I've checked gst-plugins-bad1.0
> 1.12.4-2 and:
> 
>  * gst-plugins-bad1.0 1.12.4-2 => OK

Ok, good.

> 
>> Can you also check the other packages that failed to build (gmic and
>> vips)?
> 
> Unfortunately, both were built on the right versions and they fail; gmic
> with:
> 
> = = = = = = = >8 = = = = = =
> dh_install: Cannot find (any matches for) "etc/bash_completion.d/gmic"
> (tried in ., debian/tmp)
> 
> dh_install: gmic missing files: etc/bash_completion.d/gmic
> dh_install: missing files, aborting
> = = = = = = = >8 = = = = = =

That's #892123.

> while vips on some weird missing dependencies where openexr is not
> involved, it seems.

Can you file a bug for this?

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.

Cheers,
Emilio