an update to automake-1.11?

[Braden McDaniel]

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.

Obviously there is a class of Fedora package maintainers who are
comfortable incurring that risk and prefer simply to pick up the pieces
when such breakage occurs.

And then there are those of us who don't mind doing 5-15 minutes of work
for the insurance that updates to Fedora's autotools will have no impact
on our package's build.

-- 
Braden McDaniel <braden at endoframe.com>