There is one major issue with this package:

There are also other issues like * Instead of doing mv $RPM_BUILD_ROOT/%{_prefix}/local/bin/* $RPM_BUILD_ROOT/%{_bindir}/ you need to set the prefix during building * Use the latest scriptlets http://fedoraproject.org/wiki/Packaging/ScriptletSnippets * No more --vendor="fedora" in new packages

At least ffmpeg you use is old. Afaik the 0.5 release corresponds to revision ~17500.

Can't you get these patches (that you mention in that email) accepted into their respective upstream projects?

I don't really know anything about how it's packaged or if their src.rpm might be useful, but it works fine on Fedora 12.

After a detailed IRC discussion with the authors of HandBrake, it is their wish that if HandBrake can not be compiled completely with the bundled libraries (all of them), that it not be submitted to the rpmfusion, or any other repo.

Therefore I am closing this request.

(In reply to comment #5) > Have you had any luck with ffmpeg, x264 or a52dec in terms of getting the > patches upstream? The authors did mention that all patches had been submitted upstream.

(In reply to comment #11) > After a detailed IRC discussion with the authors of HandBrake, it is their wish > that if HandBrake can not be compiled completely with the bundled libraries > (all of them), that it not be submitted to the rpmfusion, or any other repo. That is very unfriendly of them. Don't they wish to cooperate with downstream distributors?

Actually you could still do it without their approval. After all, the licence allows you to do that.

So did they just send patches upstream or did they actually work with upstream to have them applied to upstream source trees?

**especially** considering their official stable release has no Linux packages in their download section.

On Sunday, 15 November 2009 at 23:30, RPM Fusion Bugzilla wrote: > http://bugzilla.rpmfusion.org/show_bug.cgi?id=679 > --- Comment #14 from Bernard Johnson <bjohnson(a)symetrix.com&gt;  2009-11-15 23:30:14 --- > (In reply to comment #12) > > (In reply to comment #11) > > > After a detailed IRC discussion with the authors of HandBrake, it is their wish > > > that if HandBrake can not be compiled completely with the bundled libraries > > > (all of them), that it not be submitted to the rpmfusion, or any other repo. > > > > That is very unfriendly of them. Don't they wish to cooperate with downstream > > distributors? > > It seemed to come down to: > Lack of control over the changes to libraries they thought were important = > increased support requests to their site for "buggy packaging". > > Even if we were able to get all patches upstreamed, they insisted that we > should be bundling the libraries so that nobody can make updates or patches > that break HandBrake.  Personally, I think this is paranoid, as we know that > when ABIs are respected, it's not likely random breakage will happen. I agree here. That's too paranoid. If a libary update breaks something, it's a bug in the library or in the way that apps use it. Either way, that should be fixed. And, as you say, ABI checks should catch most of the cases. >  However, > the recent updates to gtk2 broke the stable 0.9.3 version (their Ubuntu build > and my test build), which was cited as an example.  I know that things like > this are extremely rare though. > > Although they have release versions, I don't know if I'd go so far as to call > them "stable" since many times the bug reporters are asked to upgrade to trunk > and then retry the bug. So, in terms of supporting only the latest trunk, that's similar to what MPlayer and FFmpeg do. I don't see much complaints about streams of Fedora users complaining directly to the developers. We can keep pushing the latest trunk to rawhide, but once we have a release, we often can't make a major update easily. I guess HB developers are having a hard time understanding that they cannot control which version of their software people will want to use. > > Actually you could still do it without their approval. After all, the licence > > allows you to do that. > > Yes, I know, but it would still cause a burden for them.  Also things like > Help->Guide direct to their wiki page for help.  This page does/will contain > *current* version information, not necessarily the version in repositories. > This would be a problem for both us and them. > > If I was able to completely decouple from the upstream support, I would look > into it again. Adding a repo tag to the version string displayed by HandBrake would give enough indication that it's not a vanilla version. It's what we do with MPlayer and FFmpeg as well. If upstream wants to deny support to users of our packages, it's their right to do so. > > So did they just send patches upstream or did they actually work with upstream > > to have them applied to upstream source trees? > > I don't know, I suspect a little of both. My understanding is that at least one > upstream has not changed in years - that makes it hard to get patches in :) Well, we could look at these patches and see if they're worth incorporating into RPMFusion packages if upstreams are really dead. However, if upstream has rejected the patch or if HandBrake developers haven't done their due diligence in getting their patches accepted upstream, then maybe the patches aren't so essential after all. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages."        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"