[Resending, because my previous mail CC'ing the maintainers of reverse (build-)dependencies seems not to have made it to the list.]
Hi, On 29.04.2015 20:56, Alessio Treglia wrote: > I am afraid that I have to revive this discussion once again now that > Jessie is out as we have plenty of time before starting doing any > major work for Stretch: it's really the right time to make a final > decision about this subject. > The need to get this dichotomy solved may be found in Moritz's last email: > > On Wed, Apr 29, 2015 at 7:22 PM, Moritz Mühlenhoff <jmm at inutil.org> wrote: >> To properly migrate over a daemon they need to co-exist for a stable >> release, while a lib does not. Stretch will only have one of them. > > [snip] > >> Having both for a year along each other will only waste people's time. Now >> at the beginning of the release cycle is the time to make a decision, >> not by dragging things into a year as of today. Picking one of the two >> won't be any simpler in 12 months. > > It appears clear to me that the security team wouldn't be too happy to > support both FFmpeg and libav: > Therefore the question still remains: > > On Tue, Aug 26, 2014 at 11:36 PM, Benjamin Drung <bdrung at debian.org> wrote: >> So I am asking you: Should we ship libav or FFmpeg? Can we reach a >> consensus on this topic? Currently FFmpeg [1] and Libav [2] packages coexist in unstable without any technical problems. However, unless someone can convince the Debian Security Team that supporting both in a stable release would be acceptable (I couldn't), a decision has to be made. I think FFmpeg should be chosen, because it is better than Libav in practically every way: * It has more features, e.g. it supports more codecs/formats/filters and devices [3]. * Some applications require some of those features and thus don't work with Libav, e.g. chromium, currently using an embedded copy [4]. * Bug fixes in FFmpeg are only rarely cherry-picked to Libav, while most changes in Libav are merged into FFmpeg. Thus Libav contains bugs not present in FFmpeg. (See e.g. #783616 [5] for a typical example.) * The previous point also applies to security fixes. (See e.g. CVE-2015-3417 [6] for a typical example.) Thus I'm proposing a transition from FFmpeg to Libav. The transition consists of two parts: libraries and command line tools. Transitioning the libraries could be done by switching build-dependencies from lib*-dev (built from src:libav) to lib*-ffmpeg-dev (built from src:ffmpeg). But because this would require making source changes to all reverse build-dependencies, I think it would be better to rename the libraries from src:libav to lib*-libav-dev and those from src:ffmpeg to lib*-dev. Then binNMUs would be sufficient for most reverse build-dependencies. Transitioning from the libav-tools to the ffmpeg binary package has to be done for all packages depending on libav-tools. Otherwise they would become uninstallable. Adjusting recommends/suggests would also be good, but is not as important. Reverse build-dependencies requiring work: * blender: FTBFS #783838, fixed in experimental * dvswitch: FTBFS #747868, not in testing * gpac: uses private libavformat define #783879 * gstreamer0.10-ffmpeg: FTBFS #720796, should be removed * gst-libav1.0: needs build-dependency on libavresample-dev * jitsi: FTBFS: #759835, fixed in NEW * mpd: needs version from experimental, see [7] * paraview: FTBFS #783842 * taoframework: hardcoded sonames need to be updated * xbmc: to be replaced by kodi (in NEW), which uses FFmpeg already Reverse dependencies of libav-tools: * devede supports both * dvd-slideshow drop ffmpeg-avconv.patch * dvdwizard drop port-to-avconv.patch * ffdiaporama supports both * gerris drop 04_replace_ffmpeg_by_avconv.patch * ifetch-tools no direct use (why the dependency?) * kdenlive supports both * miro drop 140_use_avconv.patch * performous-tools drop use-avconv.patch * python-satellites needs one-line patch for video.py: avconv -> ffmpeg * python3-audioread drop avconv.patch * tribler supports both * videotrans drop 03-ffmpeg_to_avconv.patch * winff-gtk2,winff-qt supports both * zoneminder drop libav_path.patch * zoomer needs one-line patch for zoomer: avconv -> ffmpeg Other packages needing changes: * x264 avconv -> ffmpeg in debian/tests/encode-testimage * imagination drop 30_avconv_port.patch * transcode drop 07_libav9-preset.patch Please let me know if you have better ideas about this or think that something above is not correct. Best regards, Andreas 1: https://tracker.debian.org/pkg/ffmpeg 2: https://tracker.debian.org/pkg/libav 3: http://lucy.pkh.me/diff 4: https://bugs.debian.org/763632 5: https://bugs.debian.org/783616 6: https://security-tracker.debian.org/tracker/CVE-2015-3417 7: https://anonscm.debian.org/cgit/pkg-mpd/pkg-mpd.git/tree/src/decoder/plugins/FfmpegDecoderPlugin.cxx?id=db29be648eb67589e71bec3f3a5218c1f546c6c5#n429 _______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
