Yavor Doganov <ya...@gnu.org> writes: > Probably you're right; I guess this is due to the misarable experience I > had in the past, with Gtk+/GNOME packages in particular. Even now if I > look at the packages I maintain, they're full of underquoted and > obsolete macros. These things are fixable, as you say, but some > upstream maintainers are very reluctant to incorporate changes to the > build system. I have seen my proper m4 quotation deliberately removed > and classified as "obfuscation". In this age, some people still use > AC_TRY_* macros in new packages because that is what they copy/pasted > eons ago.
Yes, you're not wrong. I suppose the caveat I should attach to my experience is that I'm a fairly experienced Autoconf user (dating back to the version 1 days, in fact, although I only started using it in earnest with version 2), so while writing detailed m4 macros is usually beyond me, I can fairly easily debug and fix most Autoconf scripts. People with less experience will be less comfortable being aggressive about this. I do wish that more maintainers would treat Autoconf with the same care that they would treat, say, their C or Perl or Python coding style and stay similarly current in the language. It's not that hard to go through the changelog of new Autoconf releases and adjust for new recommended macros. But if you don't do it regularly, the accumulated work becomes intimidating. > What about packages that use a custom bootstrap script and/or gnulib? > Should gnulib be updated too? I would not update gnulib. A good case can be made to do this, but, as you say, it's dangerous. The huge difference with gnulib vs. Autoconf and Automake is that the latter don't contain any code that actually makes it into the final binaries. You can get some weird bugs, but by and large the software just doesn't build, or, worst case, builds with the wrong libraries. Updating gnulib can violate the expectations of the actual code, and possibly even introduce security vulnerabilities. That's a lot trickier. Most of gnulib *should* be inactive on a current glibc system, although I know that's not always the case. > What about packages which have AC_PREREQ for an Autoconf version that is > not yet packaged for Debian, or depend on a new Automake version/feature > (a minor issue, but it has happened in the past)? This used to be quite common, but honestly I've not seen it in years. A lot of the concerns that people have about always running autoreconf were completely valid and correct five years ago or so, but they've gotten a lot more stable (in part because upstream development of the projects has died down a bit again). > I also wonder why debian/autoreconf is needed given that autoreconf > is recursive. I don't think autoreconf can always figure out what to do when the files are buried in some random subdirectory without anything at the top level. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87zjg9g5ci....@windlord.stanford.edu