On Thu, Jul 9, 2009 at 9:47 AM, yersinia <yersinia.spiros@xxxxxxxxx> wrote:
And for gcc ecc. - so not only "compat" package but "upstream" package - without support as it is but if my user want, why not ?It is not hard at all to have ALL the version of autotool installed. Simply pick oneOn Tue, Jul 7, 2009 at 6:45 PM, Braden McDaniel <braden@xxxxxxxxxxxxx> 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> Perhaps but it doesn't decrease the work that the maintainer has to do.
> > Fedora's autotools chain.
> >
It very well might if Fedora upgrades to a new autoconf, automake, or
libtool that is not 100% backward compatible with the previous version.
(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.
Regards
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
