On Mon, 2008-04-21 at 21:28 -0600, Eric Blake wrote: > -----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.
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 autoconf. That's what I am talking about. Ralf
