Re: autoconf-2.62 doesn't build on RHEL4

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Ralf Corsepius on 4/21/2008 7:32 AM:
|> | (Time for me to abandon supporting RHEL-4, I suppose ;)
|>
|> Or manually install a newer m4 on that platform yourself.  Our decision to
|> require newer m4 is intentional, as older m4 have bugs that can cause
|> autoconf to create broken configure output.
| Technically true, but ... replacing a central tool like m4 from a distro
| aiming at long term stability isn't necessarily a clever idea :/
|
| I regret having to say so, but to me this has several implications:
| * RHEL and other "LTS distros" disqualify as development platforms.

Wait a minute.  You are telling me that you want to install a newer
autoconf onto an LTS distro, but not install a newer m4 onto the same LTS
distro.  When the LTS distro is ready to upgrade to autoconf 2.62, it is a
given that they will also provide and updated m4 along with it.

| * Packages using autoconf will stay with outdated versions of autoconf
| because maintainers of "LTS" distros will refuse to install the
| infrastructure required by newer autoconfs.

And they have that freedom.  Just because there is a newer, less buggy,
autoconf available doesn't force people to upgrade.  But for the packages
I work with, the benefits of upgrading outweigh the lag time in waiting
for distros to catch up.

| * Package vendors/distributors are being forced to find work-arounds to
| allow their customers/users to use their projects.

Then complain to your distro that they need to provide a newer m4.  After
all, m4 1.4.5 was released 21 months ago, which is quite long in computer
science terms.  The more pressure a distributor gets, the more they will
realize that people want to use the improved upstream software.  In
particular, if distros aren't informed about the broken configure files
that can be generated by m4 1.4.1, they have less reason to consider the
need to offer a newer m4 as part of their stable offerings.

|
| For the moment, I have decided stay with autoconf-2.61 for our works to
| avoid this kind of hassle  :(

I see the situation like this - either you design your package such that
anyone can develop it on an ancient platform, and thus stick to older
autoconf and m4 (and their included bugs), or you require that developers
for your package (but not users) have an up-to-date system (even if it
means manually installing things above and beyond what their stable distro
provided in order to develop on that platform).  If you used autoconf
correctly in your package, then distros should not need to rerun autoconf
on your tarballs, and thus, they should not care whether your version of
autoconf when generating the tarball is newer than what they offer for
stable development projects.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkgNW2sACgkQ84KuGfSFAYC9AQCdGeU5bnJB3jb7LUUos8a22kq7
/80Ani1G+YW2XiEXGlfltcfUER4UV1Nk
=eepe
-----END PGP SIGNATURE-----