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

[Andres Mejia]

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.
>
> Cheers,
> Reinhard
>
>
>
> _______________________________________________
> pkg-multimedia-maintainers mailing list
> pkg-multimedia-maintainers at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

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.

~ Andres