Re: more build sherrif-ery (and a touch of auto*)

[Daniel Reed <n ml org>]

On 2004-11-12T14:09-0500, Havoc Pennington wrote:
) On Fri, 2004-11-12 at 12:02 -0500, Daniel Reed wrote:
) > /bin/mv's command line options may be changing in one of the next releases
) > of the GNU Core Utilities. Utilities like /bin/chown have changed their
) > interface in the past as well (causing script breakage).
) They might *get away* with this for some peripheral change or wacky
) aspect of the interface that almost nobody was using, but if they try
) making any kind of substantive break they are going to get lynched (and
) very rightly so, as even a nonsubstantive break is probably wrong).

The chown behavior that changed had to do with allowing "." as a separator
between user and group for compound changes.

Previously, the command ``chown left.right target'' was interpreted as
changing the file "target" to be owned by user "left" and group "right".
Relatively recently, a standards body acknowledged that some systems allow
periods within user names, and that the syntax ``chown left.right target''
could be ambiguous if there is both a user "left.right" and a user "left"
and group "right". The chown command was changed so that ``chown left.right
target'' always interpreted the first argument as user "left.right", with
alternate syntax ``chown left:right target'' being the only way to change a
user and group at the same time.

In recent releases, a "do what I mean"-style behavior has been introduced.
The command ``chown left.right target'' will first check for a user
"left.right" and, if it exists, use it. Otherwise, it will check for a user
"left" and a group "right" and, if they both exist, use them. Only if
neither case matches is an error sent. This can still cause ambiguous
behavior, though, in the aforementioned case where user "left.right" and
user "left" and group "right" both exist, so "left:right" is still the
preferred syntax, but at least the behavior used is now defined for future
release of coreutils.


The mv command may be extended to support different behaviors for dealing
with symbolic links. In some situations, it has been discovered that
coreutils' mv behaves differently than Solaris' and other systems' mv
command, so the default behavior may need to change as well, with new
command-line arguments to allow users to explicitly state which behavior
they intended.


) Let's take an example where it was handled sanely. mktemp() is an
) inherently broken function.
) Choice 1: change the signature of mktemp() and start crashing programs.
) Choice 2: add a new interface, mkstemp(), add a compile warning if you
) use mktemp(), and document that mktemp() is deprecated.

Newer versions of the autotools do commonly print warnings when older
routines or syntax are used (in lieu of the newer autotools simply
breaking). In Autoconf, the API can be identified *by* the call signature,
not just the routine names. For example, AC_INIT() has changed its arguments
several times without breaking compatibility; the number and types of
arguments changed, and newer versions of Autoconf sanely dealt with scripts
written using the old syntax. The same is true for AM_INIT_AUTOMAKE() and
similar routines.

The actual related problem is when a change is made that can not be
identified and handled by the newer tool. These are situations, however,
where the build control file itself may have been poorly written in the
first place, to the point where its behavior could change within one API
version of the autotool that uses it.

An example could be a configure.ac that modifies Autoconf-private variables
to bypass cache checks combined with a point release that changes the
Autoconf-private variable Autoconf uses (which is considered acceptable
without changing the API version). These are the types of scripts that cause
the most problems when upgrading between the autotools, but these are also
the types of scripts that are the most vulnerable to random, untrackable
breakage even without autotool API changes in play. These scripts must be
fixed, and having API bumps cause parse errors *helps* track down these
problems.

There are some situations where it is determined the API has to change in
incompatible ways. To handle these situations, Autoconf includes a utility
called "autoupdate" which will scan a project's build control files and
attempt to modernize their syntax.


) > If there is an insistence that packages' build scripts must be generated by
) > a particular version of the autotools
) There's no insistence on a particular version; the insistence is on a
) particular *interface contract* given a particular *name*

The best I can say is that the autotools are designed so that such a
contract does should not be necessary. The autotools do attempt to "do what
you mean" in many cases. However, sometimes, as new environments gain
prominence and new problems arise, older syntaxes have to be abandoned for
cleaner, less-ambiguous, and/or more-powerful replacements.

Fundamentally, the issue brought up is that behavior within Automake and the
rest of the tools change between releases. Versioning the API provider helps
when versioning the routines and syntax forms themselves fails. The
autotools try to version based on the routines called and the syntax used,
not by the version of the tool invoked to do the processing. It is always
expected that developers and packagers will use the latest version of the
tools.


) But there has to be an explicit porting step if we can't guarantee that
) the new version is intended to provide the same interface contract.

This is part of the testing procedure for new releases. If there are
situations where the build control scripts are known to be correct under the
modern interpretation of "correct", but the autotools' syntax-compatibility
support breaks down, please report it as a bug. The code can be inspected,
corrected if needed (such as with the "do what I mean" change to chown), and
test cases can be added to the test suite to ensure the support does not
fail similarly in the future.

-- 
Daniel Reed <n ml org>	http://people.redhat.com/djr/	http://naim.n.ml.org/
What makes a man great? A man may be great in his aims, or in his
achievements, or in both, but I think that man is truly great who makes
the world his debtor... who does something for the world which the world
needs and which nobody before him has done or known how to do. -- Rupert
Gould [Longitude]