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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
