Policy proposal: generate packages when autotools update

[Kean Johnston]

All,

I would like to propose a development policy change.

Back in the monolithic days, when everything was configured with Imake,
if a target platform made changes to its .cf file, there was a guarantee
that the whole tree would be affected by those changes. This was an
important part of maintaining a platform port. Now in the modular world,
we use external tools that have nothing to do with X.org as the way to
configure for platform independence. The problem is, if those tools are
updated, there is no universal update of all of the X.org modules that
use that tool. One particular culprit is libtool. This is a highly
platform-specific tool, and updates to recent libtool mean the
difference between something working on a platform or not.

What I would like to propose is that the X.org team sets a standard
set of autotools and their versions that are used, and when one of
those tools changes revision, that it causes a full regeneration of
all of the tarballs, even if no actual source code has changed. The
reason being, these generated files (the configure scripts, libtool
etc) *are* now part of the source code, and form an integral part of
X.org's stability (or lack thereof if they are broken), and that
changing these tools should be considered the moral equivalent of
changing a bunch of .cf files in the old world order. Given this,
the time to change versions is probably best made part of a normal
release cycle.

As things stand, its a bit difficult. Some packages were configured
with automake 1.7, some with automake 1.9, some with autoconf 2.54,
some with 2.59 etc. I propose for 7.2 we standardize on:

   autoconf 2.60
   automake 1.10
   libtool 1.5.22

Comments?
-- 
"Your self-crippling is your own business just as your limitations
  are society’s burden" -- Dan Simmons