On Sun, Nov 15, 2009 at 7:33 PM, Dominik 'Rathann' Mierzejewski
On Sunday, 15 November 2009 at 23:30, RPM Fusion Bugzilla wrote:
> --- Comment #14 from Bernard Johnson <bjohnson(a)symetrix.com> 2009-11-15
> (In reply to comment #12)
> > (In reply to comment #11)
> > > After a detailed IRC discussion with the authors of HandBrake, it is their
> > > that if HandBrake can not be compiled completely with the bundled
> > > (all of them), that it not be submitted to the rpmfusion, or any other
> > That is very unfriendly of them. Don't they wish to cooperate with
> > 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.
> 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
> them "stable" since many times the bug reporters are asked to upgrade to
> 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
> > 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.
| MPlayer http://mplayerhq.hu
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
(starts at the bottom)
Honestly, their attitude towards 0x100 and, calling people retarded
(page 5 and probably other places) among other insults, and the fact
that a main developer actually used the term "luser" (page 5) tell me
that we need not be concerned about them.
Whatever course we decide regarding the libraries, I think it should
be packaged without consideration for their feelings. I'm all for
having a good relationship with upstream... but wow.
Just my 2c
P.S. - 0x100 was way nicer and held out waaaay longer than I could have.