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

[Havoc Pennington <hp redhat com>]

On Fri, 2004-11-12 at 04:17 +0100, Chipzz wrote:
> 
> This means we're going to be having trouble with every single new
> release of automake.

A symlink causes trouble with every single new release, because packages
get behavior they don't expect.

If the package refers to "all known-working versions" i.e. a whitelist,
then the package will always continue to build. If a new automake comes
out, then someone tests with the new automake and adds it to the
whitelist. Until then the package automatically uses existing, already-
installed automake versions. Remember, it's normal (and necessary) for
people to have multiple versions of automake installed.

Look, this isn't theoretical. I've had tons of problems building from
CVS and within Red Hat RPMs over the years due to the "we call an
automake binary of unknown semantics" issue. Nobody would even
*consider* breaking /bin/ls or /bin/rm in an incompatible way while
keeping the same name for the binary. There is a very well-known
programming principle: if code module A calls code module B by name,
then there has to be an interface contract for what code module B will
do when invoked by that name. Otherwise stuff breaks all the time.

If someone wants to stand up and advocate that:
 - we change /bin/rm to take different command line options and/or 
   behave differently every 6 months
 - we keep a symlink /bin/rm that points to the latest version
 - scripts should use the symlink, even though the scripts
   will break every 6 months

Then I can take the argument seriously that bindir/automake is a
reasonable binary name to use. But until someone advocates it for rm, or
strcpy(), or any other use-a-name-to-get-an-interface situation, I don't
see how automake is different.

So who is going to advocate treating rm this way? Bueller?

> I think we should rather insert a warning wrt something like:
> 
> "The latest version this package was tested with was x.yy. It may or may
> not work on your system since you appear to be having a newer version."

This would maybe be fine as a last resort if and only if the person did
not have any of the versions on the whitelist. Though I bet you would
still get bug reports, since the warning would scroll off the top unseen
and then you'd get reports of the strange failure later in the build.

However, latest automake should not be used if anything on the whitelist
is available.

> What I think would be sensible is specifying a REQUIRED minimal version
> and a TESTED maximum version - going below the required minimal version
> should generate an error, going above the tested maximum version should
> generate a warning.

Tested (and supported-by-the-package-owner) versions should always be
preferred if they are installed. e.g. if you report a GTK+ build problem
with any version but the one they support, they will tell you to jump in
a lake.

And I'll do the same with my modules; I'd love patches to port to a new
automake, but once I port, I'm not going to care about bug reports where
people are using the old automake. There's always going to be one
automake version I support and care about. And I want that version to
parallel install with all incompatible versions, so that my users/co-
developers can always install it (even if they work on other modules
that require a different automake).

Havoc