As we all no doubt know by now there are some annoying backwards
compatability problems with the GNU Auto* tools, most significantly (at
least with respect to packages I've worked on so far) in Automake.

However from a developer's point of view some of the new features and
fixes in the newer releases of these tools have been long awaited.
This is what has been own motivation for upgrading to the current
releases of these tools.  For a long time I kept current versions
manually installed in /usr/local, and left pkgsrc to its own.  However I
got tired of playing PATH games (and making mistakes doing so), and so I
decided it was time to try moving my pkgsrc versions up-to-date too.
Recently I submitted PRs containing an update to devel/autoconf-devel
(which has already been checked in), and a new devel/automake-devel
(which sadly seems still stuck in the PR db).  Amazingly after doing
that I was able to rebuild quite a few packages that needed one tool or
the other with only minor tweaks.

At first I thought there would be few enough packages needing local
tweaks that I could just modernize all of them (as I encountered and
needed them).  However I met my match with graphics/gdk-pixbuf.  It was
not difficult to fix its configure.in to work with autoconf-2.53.
However its collection of Makefile.am's were another story entirely.
Given that gdk-pixbuf is just one minor package in the massive GNOME
project, and given their developer documentation doesn't even seem to
mention which versions of the Auto-* tools should be used, let alone any
plans for migrating to new versions, it seems prudent for NetBSD pkgsrc
to just avoid rewriting the whole mess from scratch.  I certainly didn't
want to learn enough about the GNOME builds and their NetBSD hacks to
rewrite for automake-1.6.1 anyway...  :-)


So, unfortunately it seems with a complex collection of packages such as
those in pkgsrc it's impossible to expect any one release of these sorts
of tools to cover all the packages that might need them.  Even if only a
relatively few packages need custom tweaks or fixes to their
configuration and build mechanisms, it seems inevitable that eventually
there will be a need to support multiple releases of the Auto* tools in
pkgsrc.


With these two driving forces in mind I've been working on a scheme that
will allow at least two releases of these auto* tools to be installed
and used simultaneously.  I've renamed the currently used devel/autoconf
and devel/automake modules to devel/auto*-old respectively, modifying
them in the process so that they can be safely installed simultaneously
with any other auto* release (currently I add the standard
--program-suffix=-$VERSION to CONFIGURE_ARGS, internally rename their
directories with version-specific suffixes, and prevent the installation
of their info files).  I'll submit those in a PR right away....

Then for those packages that need only minor tweaks to use the new auto*
tools, I've simply created/fixed some patches for then and continue
using the default auto* commands as before.  For example this is what
I've done with the new net/netsaint-* packages I've been promising to
send-pr.  For packages which require too much effort to convert (and
especially those which are unlikely to be converted by their authors any
time soon), such as gdk-pixbuf, I modify their builds to depend on the
auto*-old tools and to explicitly invoke the "old" commands using their
"versioned" names appropriately.

I propose that with the addition of my new devel/auto*-old packages that
the devel/auto*-devel "current" releases be renamed to be the default.

It should then be realtively simple to just mechanically go through all
existing packages that need to use the auto* tools for building and
modify them to build-depend on the auto*-old names and to use the
versioned command names (as I did for gdk-pixbuf).  Then as these
packages are upgraded they can be tested with the new tools, and
modified to use the default auto* names if they work, or if indeed the
developer has upgraded too and the new tools are now required.




In theory this scheme can be extended to allow arbitrary numbers of
different releases of any package to be simultaneously installed, though
if that's the goal then it would be better to provide some flag which
can switch off the implicit conflict detection between different
versions of the same package so as to avoid having to come up with yet
more names to go in parallel with automake-old, etc.  I.e. for those
packages which are engineered (or locally fixed) to allow simultaneous
installation of different releases just treat the whole PKGNAME as the
package name and pretend there is no version suffix.  I haven't yet
explored the deeper implications of this idea yet though and I suspect
on first glance that some changes to pkg_install may be necessary in
order to make it work properly.

(note that future releases of the GNU Auto* tools are expected to allow
simultaneous installation of different incompatible releases -- i.e. the
next time some backwards incompatability is introduced their install
directories will be renamed and internally tools like autoreconf will
explicitly call the other commands by their version-ed names, as they do
now with the current releases)

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods@acm.org>;  <g.a.woods@ieee.org>;  <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>