[FFmpeg-devel] Reintroducing FFmpeg to Debian

[Niv Sardi]

El 28/07/2014 08:53, "Henrique de Moraes Holschuh" <hmh at debian.org>
escribió:
> 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).

Not really, ffmpeg is packaged as a secondary multimedia library, the
default one still being libav. If these packages get traction, we can think
of moving ffmpeg to be the default (and ship if we wish libav with the
soname change).

The package will be of use for the ffmpeg command line tools, and for the
maintainers that decide to make the switch.

For now, your binary third party games will have to link against libav.

> 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.

That's been discussed and ruled out in favour of not overstepping libav's
namespace.

> 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.

That is premature, let's deal with this issue when we have more data.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20140728/1c6281b2/attachment.html>