<div class="gmail_quote">On Thu, Jul 9, 2009 at 9:47 AM, yersinia <span dir="ltr"><<a href="mailto:yersinia.spiros@gmail.com">yersinia.spiros@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="h5"><div class="gmail_quote">On Tue, Jul 7, 2009 at 6:45 PM, Braden McDaniel <span dir="ltr"><<a href="mailto:braden@endoframe.com" target="_blank">braden@endoframe.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Tue, 2009-07-07 at 01:17 -0700, Toshio Kuratomi wrote:<br>
> On 07/06/2009 08:09 PM, Braden McDaniel wrote:<br>
> > On Mon, 2009-07-06 at 16:36 -0700, Toshio Kuratomi wrote:<br>
> >> On 07/06/2009 03:57 PM, Braden McDaniel wrote:<br>
> >>> On 7/6/09 6:10 PM, Toshio Kuratomi wrote:<br>
> >>><br>
> >>> [snip]<br>
> >>><br>
> >>>> Introducing side-effects is something to watch out for but<br>
> >>>> patching configure instead of the true source is a short term fix, not a<br>
> >>>> long term solution.<br>
> >>><br>
> >>> *Any* patch should be viewed as a short-term fix. A patch that needs to<br>
> >>> persist indefinitely suggests broken maintainership somewhere along the<br>
> >>> line--either upstream, of the Fedora package in question, or elsewhere<br>
> >>> in Fedora's infrastructure.<br>
> >>><br>
> >> <nod> But one of those patches is upstreamable and the other is not.<br>
> >> The upstreamable patch is a step on the road to the long term fix. The<br>
> >> non-upstreamable one is a dead-end.<br>
> ><br>
> > Creating a patch to configure/Makefile.in in no way precludes a package<br>
> > maintainer from sending an analogous patch to <a href="http://configure.ac/Makefile.am" target="_blank">configure.ac/Makefile.am</a><br>
> > upstream. So, yes, it's a "dead end" that:<br>
> ><br>
> > 1. reduces the size of the changeset between the upstream package<br>
> > and the one Fedora actually builds and<br>
<div>> > 2. improves the resiliency of the package build to changes to<br>
> > Fedora's autotools chain.<br>
> ><br>
</div>> Perhaps but it doesn't decrease the work that the maintainer has to do.<br>
<br>
It very well might if Fedora upgrades to a new autoconf, automake, or<br>
libtool that is not 100% backward compatible with the previous version.<br>
</blockquote><div><br></div></div></div></div>It is not hard at all to have ALL the version of autotool installed. Simply pick one<br>(for example for automake) version for the default (for example 1.10 ) and call<br>this package automake. If you want also automake 1.11 package this as automake-1.11 rpm<br>
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 <br>also for libtool 2.2 ecc.<br><br>
</blockquote></div>And for gcc ecc. - so not only "compat" package but "upstream" package - without support as it is but if my user want, why not ?<br><br>Regards<br>