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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
