Re: FFmpeg bundling exception for XBMC
On Mon, 2014-02-24 at 08:30 +0100, Ralf Corsepius wrote:
There are 2 strong reasons to not bundle FFMPEG:
* Users (eg. me) rebuild rpmfusion's ffmpeg with options not supported
by rpmfusion:
=> rpmfusion bundling xbmc's ffmpeg would void this undertaking and
reduce rpmfusion's usability.
While this is valid, is it a good enough reason on its own to refuse to
allow a bundling exception?
* ffmpeg is quite security sensitive (AFAICT, e.g. Google recently
reported (IIRC), ca. 1000 bugs, which reportedly were incorporated into
upstream ffmpeg)
=> XBMC's bundling imposes severe security risks on both XMBC and rpmfusion
This is a very valid reason. Do you have links so we can check whether
XBMC's ffmpeg fork has had these fixes applied? If not (especially for
any security bugs), then that would indicate that XBMC isn't doing well
at maintaining its fork, and that would sway my opinion.
That said, I am quite opposed to let rpmfusion bundle ffmpeg and am
in
favor of staying hard for didacitcal, to teach upstream XBMC that their
undertaking is counterproductive.
While I agree with your sentiment, I suspect that upstream XBMC won't
really care if we refuse to bundle ffmpeg. I don't think Fedora users
are a very large percentage of the XBMC user base. This is why I think
that in this case (again, assuming that XBMC is applying security fixes
to their fork), we should allow a bundling exception.
The main two arguments that would change my mind would be if XBMC is not
applying security fixes to their code or if someone actually produced
patches that allowed XBMC 13 to be built against RPM Fusion's ffmpeg.
Jonathan