[FFmpeg-devel] Reintroducing FFmpeg to Debian

[Reinhard Tartler]

On Sun, Aug 10, 2014 at 3:01 AM, Matthias Urlichs <matthias at urlichs.de> wrote:
> Hi,
>
> Jean-Yves Avenard:
>> Including rename of constants (code enums id for example).
>
> Another nail in libav's coffin, then.

That's one way to see it. To me, this makes mythtv unsuitable for
inclusion into Debian. Let me explain why:

> IMHO it's reasonable to expect core APIs to be upwards-compatible and keep
> deprecated interfaces around for another release or two.

This is exactly what Libav is doing: The deprecation process for
symbols, APIs, enums, etc. takes *years*, because so many software
packages in Debian and else where use them, and it is so believably
painful to change them. Just have a look at the last two Libav
transitions, and the massive amount of patches it took to get packages
fixed and eventually to get Debian to the new Libav release.

Now enter FFmpeg.

FFmpeg has a significant higher release frequency, (it seems to me
about every 3-4 months), so that you would get a deprecation cycle
that is considerably less than a year. In practice, the deprecation
cycle more or less seems to match Libav's cycle, because at least
right now, FFmpeg  tracks Libav's API. If that were not the case (and
I promise you FFmpeg would stop tracking Libav as soon as it replaces
Libav in Debian), I can almost guarantee [1] you that FFmpeg would
very much prefer to resume to the deprecation cycle the project
before: None, i.e., every piece of software is expected to keep up
with FFmpeg's master branch for reasons Jean-Yves outlines.

[1] at least statements such as
https://ffmpeg.org/pipermail/ffmpeg-devel/2014-August/160876.html
strongly suggest this (at least if you have followed  the
libavresample/libswresample mess).

>> Keeping your own static version is the only reasonable approach.
>
> That may be OK on Windows. However, a proper Linux distribution is supposed
> to be an integrated whole and not a haphazard collection of programs, each
> bringing along their own copy of core libraries and their own un- or
> semi-fixed security problems.
>

BTW Jean-Yves outlines an approach that used to be very common on the
past: Pick some particular snapshot of FFmpeg and maintain that in a
downstream project, and expect users to use that because it is too
much effort to keep up with FFmpeg's release frequency. Prominent
examples of projects that did this (and actually, still do) include
xine-lib, mplayer, xbmc, and many more. This lead exactly to the mess
I was talking about in my previous email: dozens of embedded
code-copies that were accepted into the Debian archive.

Over many years, I've spearheaded a significant effort in Debian with
packaging and in upstream with introducing a release culture in FFmpeg
(as release manager) to get to somewhat same release frequencies, so
that downstream projects at least had a chance to agree on common
versions of FFmpeg. At the time of the split, I was worried that this
work would have been in vain. Considering that most active developers
of FFmpeg at that time (which coincidentally supported my approach to
release management and frequency) joined what is now known as Libav, I
continued my work as upstream release manager in Libav, because I
consider Libav as much more suited for Debian than FFmpeg. Today, I
still firmly believe that this was the right move for Debian as a
project.

I do strongly believe that projects that require people to use FFmpeg
actually mean to use their own private fork (cf. the mythtv debacle),
and given the amount of packages in Debian, it would significantly
much more effort to "port" (or "patch" as Andreas is phrasing it) them
to some common version of FFmpeg than doing what we are doing now:
Making sure they work with the version of Libav's libavcodec.so
implementation. This thread has shown a couple of examples that
support this argument: Mythtv, but also mplayer that claims to work
with a system libavcodec.so, which is true as long as it matches the
version that is was built against. This is what makes mplayer so hard
to package, and was ultimately the reason why I requested mplayer's
removal (which is more than ironic, given that back then, I fought
with ftp-master for many years to get it included into Debian in the
first place).

On a related note: Most  Libav developers are very tired of the
constant flamewars and defamation attempts that arises from FFmpeg.
Over years, Libav tries to convinced everyone by providing usable
software releases. Nevertheless, this particular debate is very
worrisome: The silence from the Libav camp seems to not to be taken as
consent. Quite the contrary is true.

How to proceed from here? TBH, I'm not sure. Ideally, both projects
would find some common ground and "just merge" (however that would
technically look like). However, this very debate within Debian shows
that this is unlikely to happen anytime soon: There is way to much
disagreement on very fundamental questions that require agreement
within a free software project, and the hostile and aggressive tone
the majority of participants in this debate exhibit does not help with
making progress on that front either.

-- 
regards,
    Reinhard