On Sun, May 13, 2012 at 1:48 PM, Reinhard Tartler <siret...@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@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 _______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers