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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
