[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: autoconf-2.62 doesn't build on RHEL4

From: Ralf Corsepius
Subject: Re: autoconf-2.62 doesn't build on RHEL4
Date: Tue, 22 Apr 2008 07:49:25 +0200

On Mon, 2008-04-21 at 21:28 -0600, Eric Blake wrote:
> 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.

I am not upgrading the distro. I want to enable to developers to work on
my sources. Therefore, I am shipping autoconf+automake add-on packages
(Installed to /opt/...).

... now, autoconf is forcing me to also ship gm4.

To me, this is a massive regression on autoconf's part.

What will be next - bash-X, gawk-Y?

> | * 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.
Not in terms of "LTS distros" ... they measure "long" in much longer
intervals (In case of RHEL 4, 7 years).

These distros are ultra-conservative, ... security fixes only, and
hardly any upgrades ever.

> | 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.
Normally nobody needs to run autoconf ... Only developers need

That's what I am talking about.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]