FESCo Proposal for blocking older version of autoconf & automake

Christopher Aillon caillon at redhat.com
Tue May 6 15:04:37 UTC 2008

On 05/06/2008 07:44 AM, 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.

Doing it during the build is not the issue.  You can't even generate a 
patch to configure if the tool to do regenerate it is not available in 
the distro.

More information about the devel mailing list