Re: FFmpeg bundling exception for XBMC

On Seg, 2014-02-24 at 10:17 -0700, Ken Dreyer wrote: > On Mon, Feb 24, 2014 at 12:30 AM, Ralf Corsepius > <ralf.corsepius(a)gmail.com&gt; wrote: > > On 02/24/2014 07:20 AM, Ken Dreyer wrote: > >> > >> Hi folks, > >> > >> Alex Lancaster recently pointed out that XBMC upstream has completely > >> removed the option to use an external FFmpeg. > >> > >> https://github.com/xbmc/xbmc/pull/4005 > >> > >> FFmpeg has been a long ongoing saga with XBMC. The XBMC developers > >> develop their own patches to their private FFmpeg fork, and Alex and I > >> have had various success or failure over the years with unbundling > >> FFmpeg in the past. Unfortunately XBMC has recently taken steps in the > >> direction to make this harder, at least for the v13 "Gotham" release. > >> > >> The summary is that Alex and I need a bundling exception from the RPM > >> Fusion developer community in order to keep XBMC in RPM Fusion. > >> > >> ---------- > >> > >> From what I can tell, the three reasons that the XBMC developers > >> bundle FFmpeg are: > > > > > > 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. > > > > * 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 > > > > 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. > > One could say that the issue which prompted my bundling exception > proposal, https://github.com/xbmc/xbmc/pull/4005, is a direct > consequence of "teaching upstream". They've made it more difficult to > unbundle with the express purpose of influencing downstream > distributors of XBMC. > > You can see where that trajectory leads. Yes, it's all open source, > and the GPL technically allows RPM Fusion to do what we want, etc, but > Alex and I are heading down a path of maintaining an > increasingly-diverging XBMC fork at this point, and no one else has > committed to becoming a full co-mainatainer of the package in order to > share the workload, particularly the workload associated with > downstream patches. > > Alex and I know firsthand that this is not a good situation, and in > fact I don't know any of the upstream developers who are rabidly > enthusiastic about the bundling situation either. If the issues I > outlined in my previous email could go away or be reduced, I'm > confident that they would pull FFmpeg from their tree right away. > They've certainly pulled bundled libraries out over the years when > it's made sense to do so. https://github.com/xbmc/xbmc/pull/1450 is > one example. > > I'm all for Fedora's strong package guidelines - it's why I use and > contribute to Fedora. Please believe me that I wouldn't go the > bundling exception route if I felt that another choice was truly > feasible. After working on this package for years, I believe this is > the least-worst option available. > > Looking at it from another angle, it's important that our relationship > with upstream XBMC involve give-and-take. If we don't allow the > specific exception here for FFmpeg, we are certainly teaching them > something: we're souring Fedora's name with upstream and making them > care even less about our platform. > > I'm not yet at the point where I want to pull XBMC from RPM Fusion > altogether, but version 13 final will have that pull request in the > codebase, and we need to decide what to do. > > One thing that would really help to smooth over the relationship is if > we had a patch to XBMC that allowed us to add a large caveat to their > branding. It would be wonderful if we had some sort of "XBMC, modified > by bugzilla.rpmfusion.org" splash screen or logo. One of the XBMC > developers pointed me at Debian's effort with this. Debian has started > down this road, in large part because of these issues: > http://balintreczey.hu/blog/introducing-xbmc-from-debian/ . This would > be a great area of work for someone reading this discussion who could > become a potential contributor to XBMC/RPM Fusion. It would be even > better if the solution could be something extensible enough that > upstream would accept into their codebase. > > Another thing to consider Ralf is that I intend to maintain the > package in such a way that it will be trivial to switch between using > the bundled FFmpeg and the non-bundled version using a build > conditional. It should be simple for you to continue building against > your own custom FFmpeg package - you will just need to flip the > "without external_ffmpeg" conditional to "with external_ffmpeg" when > you rebuild your XBMC. See the ongoing work at > http://fedorapeople.org/cgit/alexlan/public_git/xbmc-rpm.git I like this solution > This sort of build switch is useful for a variety of reasons: 1) Given > the sheer number of bugs directly related to FFmpeg differences, > having a simple boolean switch lowers the barrier for our bug > reporters to do their own investigating, 2) It makes my efforts with > building nightly XBMC snapshots easier, since I don't have to worry > about matching all the FFmpeg versions between Fedora 21 and Fedora > 19, and 3) the build conditional makes it easier to switch the default > back to external FFmpeg if and when that day ever comes. Maybe the problem was, we jumped or bumped ffmpeg versions too quickly for XBMC, in this case switch to internal ffmpeg could be a solution, instead go with alfa versions of XBMC to released Fedora versions. We got xbmc-13.0-0.2.Gotham_alpha9.fc20 for F20 ... but when available XBMC should use external version, IMHO