[Debian-med-packaging] Select provider of libav* libraries

Fri May 1 12:03:37 UTC 2015

[CC'ed are the maintainers of reverse (build-)dependencies.
Please reply only to <pkg-multimedia-maintainers at lists.alioth.debian.org>.
If you're interested in this discussion, consider subscribing that 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