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

[Reinhard Tartler]

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