Re: Backward-compatibility in the autotools

[Eric Blake]

[dropping the bug report; this is turning into a philosophical
discussion more appropriate to just the mailing list, unrelated to the
original bug at hand]

On 01/11/2013 11:45 AM, Stefano Lattarini wrote:

>> As a rule of thumb on when to remove a macro - I would personally like
>> being able to write a configure script that works on both RHEL 5 (or
>> CentOS 5) (autoconf 2.59, automake 1.9.6) as well as rawhide (eventually
>> automake 1.14 and beyond), for as long as RHEL 5 remains a viable
>> Enterprise-level distro.
>>
> I'm quite unconvinced of the value in trying to support this.  Developers
> should just keep their tool reasonably up-to date

In an Enterprise setup, your tool is up-to-date if it is the version
pre-built by your vendor.  RHEL 5 is still sold, and still in active
support mode; and as long as Red Hat (as vendor) ships autoconf 2.59 and
automake 1.9.6 (plus security patches, obviously - the automake in RHEL
5 should not be vulnerable to the CVEs that normally require upgrading
to automake 1.11 or newer), then someone should feel free to develop
their software on RHEL 5.

The counter-argument is that you shouldn't be _developing_ on RHEL 5,
just testing.  Do your development on a modern platform, generate a
tarball, and then ensure that the tarball can still be built on RHEL 5.

But that is more work for the developer (such as me) that is actively
trying to keep a package building out-of-the-box on RHEL 5 (the way
libvirt is trying to behave).  Yes, end users of libvirt only care if
the libvirt tarball builds on RHEL 5, not if they can also do a git
checkout of libvirt.git and build from scratch.  But anytime a RHEL 5
user reports a bug, the fewer steps I have to go through as a developer
to reproduce their problem, the more productive I can be at solving more
bugs in the same amount of time.  Ergo, I really DO like being able to
build libvirt.git directly in RHEL 5, instead of writing a fix in
Fedora, building a tarball, getting the tarball onto RHEL 5, and testing
it (yes, shared directories such as NFS make tarball sharing faster, but
still not as painless as directly developing the patch on the affected
platform).

> IMHO; if they can't
> do so through their package manager, they should do so by installing
> from source.  And while I see this can be a problem for complex packages
> like Perl [1] or GCC, it is easily done for package simpler to install,
> like the autotools are.

It may be simple to install newer automake from source (and in fact, I
have often resorted to doing just that, as long as I install in a
directory that is only used by modifying my PATH).  But where it breaks
down is for reproducibility - there is something to be said for
developing code that works on a vanilla vendor install, and not where I
had to install extra packages to make it work.

> For a while, this is ok.  In fact, I plan to have AM_PROG_CC_C_O start
> issue warnings only in Automake 1.14, and be removed not before Automake
> 1.16.  But trying to keep a package working with Automake versions that
> are six, seven years apart (as 1.9.6 and 1.13 are) is asking for trouble,
> and not worth fighting too hard to support.

And that's why I'm trying to fight a battle from another end - RHEL 5
should really consider shipping newer autotools, _provided_ that newer
autotools are backwards-compatible and won't cause any packages built
for older automake to fail to build from source.  Emitting a new warning
is still backwards compatible (users compared about back-compat should
not be using -Werror).  Completely removing the macro is not.  Leaving
the macro in as a no-op, and documenting that new code should not use
it, is fine.  But breaking old code is not nice.

> 
> Also, in this case (as in the case for AM_PROG_MKDIR_P), a user still
> wanting to use use the obsolete macro can simply define it in, say,
> acinclude.m4.

Yes, documenting _how_ to remain backwards compatible is helpful, but by
forcing the user to do work in their acinclude.m4 in order to remain
backwards-compatible is not as nice as just always being backwards
compatible out-of-the-box.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature