❦ 26 décembre 2013 21:10 CET, Russ Allbery <r...@debian.org> : >> Urgent updates, like security issues, seldom need to patch the build >> system. For one hour spent by the maintainer to fix the build system to >> be able to build with a more recent version of automake or a more >> ancient version of automake, how much time is saved by a third-party >> person? Most of the time, none. > > Well, the build system is going to need to get updated to the newer > version of automake eventually, yes? Otherwise, you end up having to keep > separately-installed obsolete copies of Automake around to maintain the > source. The Debian automake package maintainer isn't going to want to > keep every version in the archive forever.
Yes, eventually, the build system will get updated. But I don't need a
FTBFS bug and a special upload for this. This takes unecessary time to
fix it only for Debian while it will eventually be fixed upstream. I am
not speaking of outdated build system, I am only speaking of automake
being a project changing rules in a backward and forward incompatible
way (subdir-objects, AM_INIT_AUTOMAKE, ...).
See for example libevent which is a well-maintained software. It won't
compile with automake 1.13 and later (because automake thinks that using
$(top_srcdir) in TESTS is broken while it worked perfectly). This will
be fixed when libevent 2.0.22 will be released. In the meantime, nobody
complained about this problem. Should we take time to fix a problem that
nobody sees?
--
Don't sacrifice clarity for small gains in "efficiency".
- The Elements of Programming Style (Kernighan & Plauger)
signature.asc
Description: PGP signature
