A patch to mdate-sh might take the form of checking (possibly only
when a command-line option is also specified) if $SOURCE_DATE_EPOCH
is set in the environment, and if so favoring that timestamp over
the mdate of its target file.
That sounds doable. Thanks. I don't think an extra option is needed; if
SOURCE_DATE_EPOCH is set, I think it's usual for tools to use it without
further ado. Isn't it?
Santiago, would doing this obviate Debian's desire to eliminate UPDATED?
For converting the epoch-seconds of SOURCE_DATE_EPOCH to DAY MONTH YEAR.
we can't assume GNU date. But I guess most people using mdate-sh will
have Automake and thus also have Perl, so the simplest I can think of is:
perl -e 'print scalar gmtime(1000)'
# outputs -> Thu Jan 1 00:16:40 1970
and then extract fields 2, 3, 5 with awk/sed/cut/whatever.
(I recently saw complaints about using awk in configure so that
"minimal" systems don't have to have it. Sigh.)
Does that sound viable? Is there a better way? Looking at
https://reproducible-builds.org/docs/source-date-epoch/
I don't see any. Detecting GNU date vs. BSD date seems overly
complicated, and besides, there are probably other dates out there.
I'd rather not even try to load POSIX strftime in Perl (as shown on that
page in the Perl example) since it hardly seems necessary.
mdate-sh already intentionally disables all localization, so at least
that's not an issue.
Or maybe keep mdate-sh unchanged, but patch the Automake rule for
doc/stamp-vti to honor SOURCE_DATE_EPOCH over mdate-sh.
Changing mdate-sh sounds preferable to me over changing Automake.
E.g., in case any non-Automake-using package uses mdate-sh. Not sure if
there are any such, but maybe. Also seems simpler. --thanks, karl.
