-----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 [EMAIL PROTECTED] -----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-----
