How do users use autoconf-archive?

[Dustin J. Mitchell]

Personally, I've been just downloading macros with 'wget' -- I
wouldn't have ever thought to download a tarball, and checking out the
CVS or git repositories was not worth the trouble.

Gnulib provides a nice example, though.  As all of you probably know,
gnulib does not do "releases" per se -- to use gnulib you download the
entire repo using git (I assume there's some non-git way to do this,
too - maybe a nightly archive).  Then you run 'gnulib-tool',
specifying the list of modules you'd like installed in your package.
This has the advantage of being able to process its own dependencies,
detect conflicts, etc.

This is nice for the user, too -- to upgrade your gnulib (e.g., on
trunk after branching for a release), just re-run the gnulib-tool
command and commit the results.  You don't have to carry around any
more files from gnulib than those which are used by the project.  Now
that gnulib has grown so large, this is quite a boon.

In the autoconf-archive case, such a scheme has the added advantage of
being able to warn users of functionality changes and other potential
gotchas *before* the cause problems down the road.  This is
particularly key for autoconf macros, since developers may not see
them break until they make a release and a user on AIX or Cygwin
complains.

I (obviously) like this model a lot, but I'm open to alternatives.  I
think we should have a defined process for including autoconf-archive
in a project, though.  What are your thoughts?

Dustin

-- 
Open Source Storage Engineer
http://www.zmanda.com