Package: debhelper Version: 11.5.3 Severity: wishlist Dear Maintainer,
While looking into some of the spotted reproducible build issues related to building on merged-usr vs non-merged systems[1] and fixed a couple of them[2][3] I was thinking that the "whack-a-mole" strategy might not be the best here. Fixing the problems per-package seems certainly doable for the current set of identified problems. What I worry about though is that it will not be easy for maintainers updating their package to a new upstream release to catch that the newly introduced AC_PROG_FOO or AC_PATH_PROG might lead to a reprocucible build issue. I was thus thinking maybe we could solve this in a way that would also have a positive effect on future introduced bugs of the same kind. While it's probably impossible to in a general way prevent all issues of the sort, just identifying the most common tools that end up causing problems might go a very long way. (Another alternative for a general approach might be to "sort PATH" so that /sbin is always before /usr/bin and /bin before /usr/bin, but that might have consquences I don't dare thinking about.) Apart from looking at the specific tools used in the already spotted reproducible build issues[1], doing a codesearch for AC_PATH_PROG and also investigating AC_PROG_* from autoconf docs[4] could be used as an inspiration to come up with with variables to set, which could be eg. MKTEMP=/bin/mktemp GREP=/bin/grep ... What do you think? Are setting these during configure unconditionally too scary? If it needs to happen in a new compat level, it likely won't have as big as an impact while also not helping in enough cases to be useful (but maybe not). [1]: https://tests.reproducible-builds.org/debian/issues/unstable/paths_vary_due_to_usrmerge_issue.html [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914907 [3]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914911 [4]: https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Particular-Programs.html Regards, Andreas Henriksson
