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

[Havoc Pennington <hp redhat com>]

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).

> In these cases, the maintainers of the changing software determined 
> their
> software's previous behavior was wrong. They furthermore determined
> that
> scripts designed around this previous [now-considered-wrong] behavior
> were
> and continue to be broken themselves, and must be fixed regardless of
> /bin/mv's or /bin/chown's interface.

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.

Choice 1 was not chosen.

There's nice inspiration here for automake: older versions could
legitimately print a warning about how they are deprecated and an
upgrade should be done. gnome-autogen.sh could do that for automake 1.4
modules.

> It is not the autotools' maintainers expectations that a wide range of
> systems will have more than one version of any of the autotools installed
> for a prolonged period of time. The API versioning scheme is something of a
> kludge to deal with large software collections with unmanageable inertia.

It's not a kludge. It's sound engineering practice used in every other
part of the system, from programming languages to libraries to binaries.

> 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*

By definition, if the interface contract is broken, the build scripts
*cannot* be generated by the new version because the behavior of the new
version when invoked with the old interface is undefined. If the new
version is defined to behave the same given the same input, then it has
not broken the contract, should not be renamed, and it is correct for
all packages expecting the old version to get the new version instead.
If the new version is not defined to behave the same, then nothing
should use the new version until it's explicitly ported.

In the best case porting is just changing the invocation name to the new
version, since the changed aspects of the interface weren't involved; in
that case, you can expect porting to happen right away. In other cases
porting may be more complex.

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.

Havoc