[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