Okay, this is a weird one. Feel free to reject the issue, we'll find a way to work around this issue.

Debian builds sudo twice: Once a "normal" version, and then a version with ldap enabled. We do that by creating two subdirectories, build-simple and build-ldap and then calling ../configure from those directories.

In this process, the sources are copied to the subdirectory by some autofoo magic and built from there. ChangeLog is not copied, so make install finds out which VCS is in use and generates the ChangeLog again on the fly.

This fails in Debian's CI environments in some situations when the unpacked tree (which a developer may have checked out from git) is copied verbatim (including the .git subdir) into a clean chroot or a container (which does not have git) and build there. In that case, make instal sees the .git subdirectory and invokes log2cl.pl which in turn errors out because the git binary is not present.

Would it be possible to either

- tweak configure into copying ChangeLog into a build directory
- only call log2cl if .git is found AND a git binary is on the path?
- have log2cl or make install detect that sudo is being built for a distribution and NOT rebuild ChangeLog on the fly (this is bad anyway since we might end up with a ChangeLog that differs from the one that you shipped with the sudo tarball since we might be using a completely different .git that you are using) or

Part of me thinks that no part of the build system is supposed to fiddle with a file that is part of the release tarball since this might trigger some weird security mechanism.

You might have some process to create your release tarball from your VCS, and generating ChangeLog should in my humble opinion be part of that process and not of make install for a distribution.

Thanks for your consideration.

Should you decide to let things stay as they are, Debian is probably going to patch the entire ChangeLog target from Makefile.in for the packages.

Greetings
Marc