On Mon, 28 Jul 2014, Norbert Preining wrote: > On Sun, 27 Jul 2014, Reinhard Tartler wrote: > > In [1], Moritz from the security team clearly stated that he is more > > than uncomfortable with having more than one copy of libavcodec in > > debian/testing. In consequence this means that any package that builds > > against the ffmpeg packages currently in NEW won't make it into > > testing either. I am therefore surprised about the given answer to the > > "More than uncomfortable" does not mean "will not be included"
Yes, it does. Someone will have to convince the security team somehow, likely by offering to do the work themselves _and_ convincing them that these new members will be around for long enough. However: The change in Debian-specific symbol versioning and sonames being done to ffmpeg so that it is co-installable with libav *is* a problem. It has to be done in coordination with the Canonical guys, so that both Debian and Ubuntu do the same thing re. ffmpeg sonames and symbol versioning. Otherwise, the ffmpeg packages will be of very limited use (useless to run third-party binary-only games ;-p). I understand perfectly that the soname and symbol versioning clash with libav is not ffmpeg's fault, but that's water (well, sewage) under the bridge. We have to deal with it. Here's an alternative proposal that should be less painful [to our users] in the long run: You need one of the two upstreams to do a *large* major soname bump (at least one order of magnitude higher than what they're currently using), so that both projects can keep evolving with little chance of soname clashes. Symbol versioning will take care of the rest, since both libs carry over their major soname into the symbol version. As it was done upstream, cross-distro/third-party compatibility problems are not increased. Debian will have to package this new "bumped" upstream release, and get rid of anything built against the old one. It will be easier for Debian if it is ffmpeg upstream that does the soname bump, otherwise we're talking about a huge number of binNMUs. But this is all academic if the security team is not prepared to deal with both libav and ffmpeg at the same time. That effectively forces a choice of either libav, or ffmpeg, and not both. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
