El 15/4/25 a las 14:52, Eric Blake escribió:
I'm not sure the exact process Debian uses to do downstream builds, but my guess is that it involves a downstream git repository for their patches to be applied on top of the upstream tarball - and it is the very act of applying those patches from git which can alter the mtime of $PACKAGE.texi, which in turn changes the date that build-aux/mdate-sh installs into version.texi, which then breaks reproducible builds.
Debian uses the original tarball plus a series of patches in quilt format (from another small tarball containing only debian/* files), which are applied in a given order before the build. So the procedure is not exactly how you describe, but the mechanism by which reproducibility may be lost is very similar.
And on that front, I could argue that anyone not building directly from the tarball, and who therefore triggers a different timestamp as part of their downstream process, should be fixing their downstream process to address reproducibility, rather than patching upstream to rip out dates just to make downstream's life easier.
Maybe a different timestamp is a change too small to regenerate the date which is used in the manual as the date in which the manual is published. Ideally, the date would be chosen and stored in a static file as part of your upstream release process, i.e. when you are about to release m4-1.4.20, and we should not change such file unless we really meant a different time. (Is this the same as "maintainer mode" or maybe those two things could be independent?) Thanks.
