FESCo Proposal for blocking older version of autoconf & automake

Toshio Kuratomi a.badger at gmail.com
Fri May 9 17:10:06 UTC 2008


Karsten Hopp wrote:
> Ralf Corsepius schrieb:
>> On Tue, 2008-05-06 at 11:02 -0400, Christopher Aillon wrote:
>>> On 05/05/2008 11:43 PM, Casey Dahlin wrote:
>>>> Matthias Clasen wrote:
>>>>> On Mon, 2008-05-05 at 23:28 -0400, Casey Dahlin wrote:
>>
>>> If you'd have read the thread, you'd have noticed I already pointed 
>>> out multiple times, if you want to keep Firefox in the distro, you 
>>> need to keep autoconf213 for the forseeable future.
>> Not at all. The firefox project should ship their infrastructure, such 
>> that developers can install it into their development environments.
>>
> 
> They do. Our Firefox rpm rebuilds just fine without autoconf213. The 
> autoconf213
> package is required to build the necessary files when the tarballs are 
> created.
> 
> FYI: I've canceled my request to block the older autofoo packages as the 
> discussion
> here showed that we just can't do that.
> I'd like to see a reviewer guideline instead that new packages should be 
> checked
> if they really need to run autofoo during the build and if they really 
> require to
> be built with ancient autofoo.
> 
So I have a few things against my initial impression of how this draft 
could turn out (Note: draft unseen of course so you might intend 
something entirely different:

1) It's micro-managing.  Packagers should know whether they have to 
regenerate configure/Makefile.in based on the patches that they're 
applying.  If we're seeing widespread use of the autotools when there's 
no need to do it then it seems like a candidate to add... but is that 
the case?  The list of packages which presently BuildRequire the 
autotools is very small so I'm not sure this is the case.

2) Having the packager and reviewer know that the package requires older 
  autotools to build raises the barrier to entry significantly.  If you 
can give us a checklist of items to look for in configure.in that limit 
the package to ancient autotools then we are in business.  This is 
something better done upstream.

Combining these and asking people who know enough to patch 
configure.in/Makefile.am to try to decide whether they can use current 
autoconf/automake instead of the compat packages could be a compromise 
solution but even there, you run into issues where the packager knows 
enough to patch:
- GTKHTML_MAX_VER=3.9
+ GTKHTML_MAX_VER=3.10

but not enough to recognize when older autoconf is arequirement.

If we really and truly want to get upstreams off of older versions of 
autoconf/automake, we need to introduce it into our toolchain and have 
every package that uses autotools invoke the current autoconf/automake 
in the build.  This will bring errors to the surface so we can fix them 
and submit the changes upstream.

Note that I think this is a horrendous idea as it completely disregards 
one of the core tenets of the autotools (the system that builds the 
package does not need to have the autotools installed) but if we want to 
have our packagers actively hunting for incompatibilities with the new 
autotools, then it seems like a necessary step.

-Toshio




More information about the fedora-devel-list mailing list