moto4lin, I give up.
Hans de Goede
j.w.r.degoede at hhs.nl
Sat Dec 29 06:59:17 UTC 2007
Kevin Kofler wrote:
> dragonauta x <dragonauta.x <at> gmail.com> writes:
>> This is what I got on bugzilla:"I'm sorry, but this is still an upstream
>> issue. The fact that the upstream author has a patch that fixes this problem
>> but is not releasing it in anofficial release does not make this a packaging
>> issues, IMHO.
>
> IMHO it does. Maintainers: In a situation like this, if there's a patch from
> upstream, please apply it!
>
> If upstream only provides the fix in the form of a commit to SVN trunk, first
> try applying the diff from SVN to the release, sometimes it just works. If it
> doesn't apply, you have 3 options:
> 1. Try asking upstream (nicely) for a backport which applies to the stable
> release. Keep in mind though that the upstream author(s) might be very busy and
> do(es) not necessarily have the time to do backports.
> 2. Backport the patch yourself. This is often fairly easy.
> 3. Upgrade to a SVN snapshot wholesale. If upstream hasn't done any real
> release for ages, this may well be the best option, however be careful, as the
> snapshot may also include regressions. It is usually a good idea to run the
> idea by upstream first, as for one they are likely to know about any
> regressions in the snapshots, and secondly, unfortunately some uncooperative
> upstreams may also get upset and hostile if you package snapshots (whereas
> others will even ask you to do just that, also depending on the state the code
> in SVN is in, thus the importance of asking).
>
> If you have a ready-to-apply patch or if you use options 1 or 2, please don't
> patch the source tarball directly, use Patch0 (or Patch1, ...). If you use
> option 3, make your SVN checkout the new Source0.
>
You forgot 4) Ask on this list if there is anyone who is willing to
backport upstream's fix for you.
>> It is my position that bugs like this need to be fixed by an upstream
>> release, particularly in cases like this. Because upstream fixes help all
>> distributions,and Fedora, effectively, forking it does not.
>
> First of all: It isn't "forking" to backport a patch which is already in the
> upstream SVN trunk. It's even less "forking" to package something straight from
> the SVN trunk.
>
> Secondly: Other distros will eventually get the fix because it's already in SVN
> trunk, so it will be in the next release. And if they want it first, they can
> backport it, just as you can.
>
> Notwithstanding all the above: It would of course be better for all distros,
> including Fedora, if there was a new stable release with the fix. However, as I
> said above, upstream may be too busy to do backports, and unwilling to release
> from the current state of the SVN trunk for reasons unrelated to the fix
> (regressions etc.). So sometimes, backporting is really the only option.
>
>> I don't believe it is Fedora's place to be tracking svn.
>
> Then backport the fix.
>
> If it doesn't apply to the stable version and you can't get it to apply, let us
> see the BZ report and the fix and I'm sure one of us will be able to help you.
>
Ah yes, thats what I meant with option 4.
Regards,
Hans
More information about the fedora-devel-list
mailing list