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