an update to automake-1.11?

yersinia yersinia.spiros at gmail.com
Thu Jul 9 07:50:56 UTC 2009


On Thu, Jul 9, 2009 at 9:47 AM, yersinia <yersinia.spiros at gmail.com> wrote:

> On Tue, Jul 7, 2009 at 6:45 PM, Braden McDaniel <braden at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090709/60509bf9/attachment.htm>


More information about the fedora-devel-list mailing list