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.
> 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.
> Does the upstream maintainer have a good reason for not having a real release
> that fixes this?
You have to ask this question to upstream themselves. :-)
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
