On Tue, Jul 7, 2009 at 6:45 PM, Braden McDaniel
<braden@endoframe.com> wrote:
On Tue, 2009-07-07 at 01:17 -0700, Toshio Kuratomi wrote:
> On 07/06/2009 08:09 PM, Braden McDaniel wrote:
> > On Mon, 2009-07-06 at 16:36 -0700, Toshio Kuratomi wrote:
> >> On 07/06/2009 03:57 PM, Braden McDaniel wrote:
> >>> On 7/6/09 6:10 PM, Toshio Kuratomi wrote:
> >>>
> >>> [snip]
> >>>
> >>>> Introducing side-effects is something to watch out for but
> >>>> patching configure instead of the true source is a short term fix, not a
> >>>> long term solution.
> >>>
> >>> *Any* patch should be viewed as a short-term fix. A patch that needs to
> >>> persist indefinitely suggests broken maintainership somewhere along the
> >>> line--either upstream, of the Fedora package in question, or elsewhere
> >>> in Fedora's infrastructure.
> >>>
> >> <nod> But one of those patches is upstreamable and the other is not.
> >> The upstreamable patch is a step on the road to the long term fix. The
> >> non-upstreamable one is a dead-end.
> >
> > Creating a patch to configure/Makefile.in in no way precludes a package
> > maintainer from sending an analogous patch to configure.ac/Makefile.am
> > upstream. So, yes, it's a "dead end" that:
> >
> > 1. reduces the size of the changeset between the upstream package
> > and the one Fedora actually builds and
> > 2. improves the resiliency of the package build to changes to
> > Fedora's autotools chain.
> >
> Perhaps but it doesn't decrease the work that the maintainer has to do.
It very well might if Fedora upgrades to a new autoconf, automake, or
libtool that is not 100% backward compatible with the previous version.
It is not hard at all to have ALL the version of autotool installed. Simply pick one