Re: automake parallel install stuff

[Havoc Pennington]

Hi,

Look, I think everyone is overcomplicating the problem here. It's
really really really really simple. Anything that is compatible has
the same name; anything that isn't compatible has a different
name. Because from the point of view of an interface user (an app), a
compatible thing implements the same interface, and is the same thing;
and an incompatible thing is a different thing. And all that's
required on the interface provider side is to give different things
different names, and give same things the same name.

There are two names that apps use. One is the automake executable
name; one is the directory name where they install third-party m4. So
those two names should change exactly when they are no longer
compatible. That's it; it's not any more complex than that.

So when deciding what variable (VERSION, etc.) to use, you simply need
to find a variable that changes exactly when compatibility changes.
If no such variable currently exists, you make up an arbitrary one,
just like library sonames are arbitrary numbers that exist purely to
covary with interface compatibility. That's what my "MAJOR_VERSION" in
GConf is, for example, though I tie VERSION to that by convention
because that helps everyone understand what's going on.


When automake is an interface user (e.g. depending on autoconf), all
that's required is to use the name that corresponds to the interface
that you want. This assumes that autoconf follows the rule that the
same thing has the same name, etc.

What I'm asking for for scripts and spec files is a name that refers
to what I mean ("automake-1.4", "automake-1.5") instead of a name that
refers to an unknown quantity ("automake") or a name that refers to
details I don't care about ("automake-1.5.1p4"). And automake should
request the same kind of what-I-mean names from autoconf.


Jens Petersen <address@hidden> writes:  
> -m4datadir = $(datadir)/aclocal
> +m4datadir = $(datadir)/address@hidden@

Here the name of your directory is over-specific, it gives many of the
same things (bugfix releases) different names. In practice this
removes the name datadir/address@hidden@ as an interface, i.e. apps
can't use this name because it changes too often. So it becomes a
policy decision that applications should install to the fixed name
share/aclocal for all versions of aclocal; which implies that m4 files
are supposed to be able to work with all autoconf versions. i.e. it
implies that share/aclocal always refers to the same interface since
the name share/aclocal never changes.

So if the change is done this way, we need a commitment from the
autoconf maintainers that share/aclocal macros will never break with
new autoconf, which I think is a silly commitment to expect, ergo I
would personally go with putting the interface version (just the
"1.4") in share/aclocal-1.4 and encouraging third party macros to go
in there. Or perhaps it's more appropriate to use an autoconf version
in the name e.g. share/aclocal-2.5x or something.


Anyhow, let's stop overcomplicating the problem. There are very few 
names that matter:

 datadir/aclocal-whatever
 bindir/aclocal-whatever
 bindir/automake-whatever

Just make them change when and only when they break. There's no rocket
science involved, just details, but the available choices for the
details should be clearly defined.

Havoc