Bug#672791: Strict internal dependencies make libavcodec53 uninstallable when updating to libav 0.9

[Andres Mejia]

On Sun, May 13, 2012 at 3:10 PM, Reinhard Tartler <siretart at tauware.de> wrote:
> On So, Mai 13, 2012 at 20:43:08 (CEST), Andres Mejia wrote:
>
>> On Sun, May 13, 2012 at 1:48 PM, Reinhard Tartler <siretart at tauware.de> wrote:
>>> Package: libavcodec53
>>> Severity: important
>>>
>>> I have now prepared a new upstream snapshot of libav at
>>> http://anonscm.debian.org/gitweb/?p=pkg-multimedia/libav.git;a=shortlog;h=refs/heads/experimental.
>>> In this new version, the SONAME of libavcodec and libavformat was bumped
>>> from 53 to 54. This is not a problem by itself and necessary as a number
>>> of deprecated APIs have been dropped. However, libavutil51 has not been
>>> bumped, but is simply newer. This fact now causes the problem that the
>>> 'old' libavcodec53, which a lot of applications link against, becomes
>>> uninstallable because of the strict internal dependencies:
>>>
>>> Depends: libavutil51 (>= 4:0.8.1-0ubuntu1) | libavutil-extra-51 (>= 4:0.8.1), libavutil51 (<< 4:0.8.1-99) | libavutil-extra-51 (<< 4:0.8.1.99)
>>>
>>> What can we do now about this:
>>>
>>> a) We could simply drop the strict internal dependencies.
>>>
>>> They were mostly a safety guard to ensure that on upstream version
>>> upgrades, all shipped libraries stay in sync. This is exactly what
>>> breaks now. Technically, removing this safety net is easy to do by
>>> dropping a few lines in debian/rules.
>>>
>>> b) somehow ship a 'new' libavcodec53 that links against the new
>>> libavutil.
>>>
>>> Yay, code duplication. We would also need to duplicate libavformat53. I
>>> think this is a no-go.
>>>
>>> c) bump SONAME of libavutil
>>>
>>> This would work, but I'd rather not diverge from upstream's SONAMES. And
>>> convincing upstream to do this to accommodate Debian's rather strange
>>> decisions with strict internal dependencies is rather not going to happen.
>>>
>>> d) something else I didn't think of.
>>>
>>>
>>> TBH, I'd tend for option a), but before going that way, I'd also like to
>>> hear your input on that.
>>>
>
> [...]
>
>>
>> I'm more inclined to go with option a) for those libraries/programs
>> that do not need the strict internal dependencies (i.e. libraries and
>> programs that are not using non-public headers and symbols). I think
>> libavutil should drop the strict dependencies if this is the case.
>
> Ah, so you suggest do have the strict internal dependencies excluded for
> libavcodec? For the sake of simplicity, I'd just drop them for all
> packages.  I've introduced the strict internal dependencies in the days
> where there weren't proper releases, and the internal APIs were much
> more in flux.  I think this has vastly improved in the mean time.
>
> Cheers,
> Reinhard
>
> --
> Gruesse/greetings,
> Reinhard Tartler, KeyID 945348A4

If libavcodec is not using any private headers or symbols from any of
the other libraries, then yes, the strict internal dependencies should
be excluded.

-- 
~ Andres