Bug 61591

Ah, but it seems to me that this may break portability, won't it?
Developers who use this would create project dists that won't build out of the
box on systems without versioned auto* scripts, after say configure.ac or
Makefile.am has been touched.

Perhaps a better solution to this, would be to use alternatives to choose which
autoconf and automake version is the default?

Broken Portability
==================

Yes, it breaks the portability -- but IMHO this is not very important, because:

- after calling 'aclocal' the RH-specific changes are reverted
- changing the configure.ac or Makefile.am is a uncommon action for end-users, 
  the developer knows what he has to do and distributors are rebuilding these 
  files by calling auto* explicitly
- other people than these above will get a message from 'missing' telling that 
  the program was not found and can call auto* explicitly
(- configure.ac without AM_MAINTAINER_MODE are erroneous and a pain for the
   end-user)


Alternatives
============

I do not see much profit in the alternative-system (not all Debian-stuff makes
sense). 'alternatives' makes system-wide settings but autoconf-2.13 vs.
autoconf-2.5 is a per-user decision. 

Such an user-decision can be done already by setting environment variables, but
it is bloat because each AUTO* program requires such a variable.

Probably, you will run into problems with the slave-links of automake also
(Version 1.4 contains 4 info-files, version 1.5  5 ones, but alternatives
requires the same count of slave links).


Other ways
==========

The best solution would be if autoconf/automake are writing the needed
program-names into configure and the Makefile.am.

Another hac^Wfix would be the modification of ./missing in a way like:

| case "$1" in
| --run)
|   # Try to run requested program, and just exit if it succeeds.
|   run=
|   shift
|-  "$@" && exit 0
|+  prog="$1"
|+  shift
|+  case "$prog" in
|+    autoconf)
|+      for flavor in "-2.53" ""; do
|+        "$prog$flavor" "$@" && exit 0
|+      done;;
|+    automake)
|+      for flavor in "-1.6" "-1.5" ""; do
|+        "$prog$flavor" "$@" && exit 0
|+      done;;
|+    *) "$prog" "$@" && exit 0;;
|+  esac
|+  set -- "$prog" "$@"
|  ;;
|esac

*** Bug 62232 has been marked as a duplicate of this bug. ***

This is becoming something of an issue, because e.g. GNOME 2.0 prereleases won't
build with an "older" autoconf or automake.  Is there any way autoconf, automake
and aclocal can be updated without breaking "compatability" (strictly, this is a
source issue rather than an ABI one, isn't it) ?

billc, in the mean time you can use
  make AUTOCONF=autoconf-2.53 AUTOMAKE=automake-1.5 \
    ACLOCAL=aclocal-1.5
etc.

Enrico, what is the reason for the
  set -- "$prog" "$@"
in your suggested change to missing?

Because I shift'ed the first argument out of $@

| prog="$1"
| shift

and want to keep the rest of 'missing' working as before, I restore $@ with the
'set -- ...' statement.

But as indicated above already, I consider the modification if 'missing' with
this hardcoded version-numbers as a dirty hack. The "correct" way will be the
modification of 'autoconf' so that it codes its version-number somewhere into
configure. 

The 'automake' case-clause is not needed for 'automake' >= 1.6 because it
encodes its version-info already.

billc: don't forget to set 'AUTOHEADER=autoheader-2.53' in the way shown above
also...

Created attachment 51965 [details]
missing patch to search for versioned autoconf and automake programs

Ok, I'm going to try with the above patch based on Enrico's suggestion.
Does it look ok?

I put the latest package at:

http://people.redhat.com/petersen/SRPMS/automake15-1.5-2.src.rpm
http://people.redhat.com/petersen/RPMS/noarch/automake15-1.5-2.noarch.rpm

so if you could bang on it, it would be well appreciated.

While I agree that the missing patch is a bit of a hack, it is quite
flexible and making configure understanding versioning will create
more portability problems I would say.  So I think the above is a
reasonable compromise.

Can someone confirm this is working as expected now with the latest packages?

A mass rebuild of the tree was run by Tim Friday and there were no build
regressions relative to public beta2.

The automake15-1.5-2 is in rawhide now.