an update to automake-1.11?

Kevin Kofler kevin.kofler at chello.at
Tue Jul 7 12:01:51 UTC 2009


Braden McDaniel wrote:
> Breaking compatibility with previous versions of automake, autoconf, or
> libtool has no impact on released tarballs made using those tools; they
> continue to work as intended because they do not depend on the presence
> of these tools.  As such, I imagine the autotools maintainers do not
> feel so great an obligation to backward compatibility as the CMake
> maintainers might.

And that's exactly what I'm complaining about.

You eschewed my question about what the advantage of this way of working is, 
in face of the obvious drawbacks, i.e.:
* changing the actual source code (and yes, it's necessary for upstream to 
change the actual source code) may require other, unrelated changes to 
account for incompatible autotools changes. Especially if upstream is using 
a fast-moving distribution like Fedora. Even if updates like that automake 
1.11 update wouldn't get pushed, they'd still have to upgrade to a new 
Fedora with new autotools at least once a year. It's unrealistic to expect 
upstreams to have a self-installed custom copy of specific autotools 
versions. A few projects, such as GCC, do that, but most upstreams just use 
whatever autotools their distro ships, which is usually not even the same 
for all upstream developers (so configure scripts pingpong between different 
autotools versions as they're regenerated by different developers).
* any bugs in the shared template snippets get copied into all packages 
using the snippet, so you have to patch lots of packages to fix something. 
The infamous lib64 rpath bug is one example (and compounded by the fact that 
upstream refuses to fix it – one upstream developer claimed it fixed in 
upstream libtool 2.1, but it actually isn't).

For me, this design is inherently broken, just like bundling libraries is 
(and Fedora has policies banning the latter in most cases), for the same 
reasons (bugs getting copied to all packages), and I fail to see any 
advantage of that way of working.

        Kevin Kofler





More information about the devel mailing list