Policy proposal: generate packages when autotools update

[Daniel Stone]

On Sat, Oct 28, 2006 at 05:36:57PM -0700, Kean Johnston wrote:
> 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.

Dear god, no.  Please.

This would mean regenerating the fonts in particular every release,
which is certainly not what we want.  The approach Debian takes (it has
a lot of esoteric ports, such as the FreeBSD kernel with GNU
userland[0], and the Hurd), is just to regenerate in-package if it's
biting it in particular.  I'd rather not randomly regenerate for no
reason; that's insane.

> 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

Mandating a standard environment to build the tarballs in is probably
sensible, but automake 1.10 is pretty bleeding edge.  Does everything
even build with that?

Cheers,
Daniel

[0]: And NetBSD kernel with GNU userland, way back when.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20061029/2d1ece3d/attachment.pgp>