[FFmpeg-devel] Reintroducing FFmpeg to Debian

[Henrique de Moraes Holschuh]

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