FESCo Proposal for blocking older version of autoconf & automake

Toshio Kuratomi a.badger at gmail.com
Tue May 6 14:02:21 UTC 2008


Karsten Hopp wrote:
> Jeroen van Meeuwen wrote:
>> Jesse Keating wrote:
>>> On Mon, 2008-05-05 at 23:43 -0400, Casey Dahlin wrote:
>>>> The gain is we decide what to keep and what not to keep based on who 
>>>> actually is willing to fight to keep it around rather than whoever 
>>>> feels like complaining on devel list. Its a corollary to "its easier 
>>>> to apologize than to ask permission," the people who notice the 
>>>> change are a tiny and far more important subset than the people who 
>>>> will complain ahead of time.
>>>
>>> It doesn't account for the developers who will have failures, notice we
>>> don't package a version of autoconf anymore and say "Screw that" and
>>> move to some other development platform which does support what they
>>> need.
>>>
>>>
>>
>> My $.02 worth of thoughts:
>>
>> One could imagine a policy in which new packages using these tools 
>> would not be accepted per-se, while the tools would still be 
>> available, packaged, for those other packages and developers that need 
>> it.
>>
>> Does such, or something similar, make sense?
>>
> 
> Such a policy would be ok with me. The whole intention for this proposal 
> was
> to disencourage usage of the old tools, not to force maintainers to 
> rewrite their
> configure scripts immediately or use another distribution.
> Nonetheless maintainers of forementioned packages should check if it is
> necessary to run autofoo during the build. Most of the times it isn't 
> and if I
> remember correctly even I am guilty of doing this due to laziness and/or 
> time
> constraints.
> 
The problem with talking about removing these packages is that the 
packages may not need to run the autotools during build at present but 
that doesn't mean they don't have to be run at some indefinite point in 
the future.

For release 1.0-1.4 of libfoo, upstream didn't require any patching so 
everything worked fine.  In release 1.5, upstream made a mess of how 
they create and deploy some utilities built with libfoo.  In order to 
fix this, you have to patch the configure.ac and Makefile.am.  Suddenly 
you need to have the autotools to be able to build.

(Note: whether you run the autotools from within the spec file or run 
them locally and then include the diff with the SRPM, you may still need 
to have matching versions of the autotools available to make everything 
work.  Getting this right needs to do a lot of upstream education before 
it can be removed from the distro.)

-Toshio




More information about the fedora-devel-list mailing list