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

Re: Remove cdrtools

Wouter Verhelst writes:

>> In my experience, this is greatly exacerbated and perhaps even
>> primarily due to older versions of autotools encouraging or requiring
>> behavior that later versions of autotools declare to be broken.
> [...]
>> The situation is not helped when these mutually incompatible programs
>> all prefer to be called "automake" or "autoconf" and, on less helpful
>> distributions, do not install themselves as automake-1.9 (etc).
> Why should that matter at all?
> Autotools are tools for the upstream developer, and have had features to
> declare what version the configure.ac or Makefile.am files are supposed
> to be used with for quite some time now. You distribute a package that
> is already autotooled; the person who compiles the software doesn't need
> autotools.
> In case they do, your way of using autotools is horribly broken.

This means the default operation of automake is horribly broken.  (See
the lengthy comment in /usr/share/doc/autotools-dev/README.Debian.gz
on AM_MAINTAINER_MODE if its problems slipped your mind.)

The usual way for people to use version control is to keep the source,
and provide scripts as appropriate to derive the program.  Because of
this, it is not common to put aclocal.m4, configure, or the other
generated files into version control.  Thus, anyone who downloads
software from version control must run aclocal, autoheader, automake,
autoconf, possibly libtool, etc.  This is when backwards incompatible
changes cause problems.

On top of the default automake behavior being horribly broken, does
that make usual revision control practices horribly broken?

Michael Poole

Reply to: