On Thu, Jul 9, 2009 at 9:47 AM, yersinia <yersinia.spi...@gmail.com> wrote:
> On Tue, Jul 7, 2009 at 6:45 PM, Braden McDaniel <bra...@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
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list