[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: an update to automake-1.11?



On Thu, Jul 9, 2009 at 9:47 AM, yersinia <yersinia spiros gmail com> wrote:
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
(for example for automake) version for the default (for example 1.10 ) and call
this package automake. If you want also automake 1.11 package this as automake-1.11 rpm
and, if the developer want, it is its choice, use this instead of the default via the autotool env var. I do this in RHEL
also for libtool 2.2 ecc.

And for gcc ecc. - so not only "compat" package but "upstream" package - without support as it is but if my user want, why not ?

Regards

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]