[Reproducible-builds] Bug#787444: Bug#787444: Bug#787444: help2man: support externally-supplied --date for reproducibility
bod at debian.org
Wed Jun 10 10:41:16 UTC 2015
On 10 June 2015 at 01:59, Ximin Luo <infinity0 at pwned.gg> wrote:
> Given the above, I think it would still be good to define SOURCE_DATE as I originally suggested:
> SOURCE_DATE = "$(date -d "$(dpkg-parsechangelog --count 1 -SDate)" --iso-8601=seconds)" # includes the TZ offset
> - if the language/tool already has/uses a ISO8601 parser in its standard library, this is as convenient as the previous SOURCE_DATE_UTC
> - if the language/tool doesn't have/use one, then SOURCE_DATE_UTC doesn't actually give us any benefits:
> - it's far easier to use SOURCE_DATE_EPOCH, if you want to play with the date programmatically
> - OTOH if you're just going to take substrings/regex-match it, this works just as easily for SOURCE_DATE vs SOURCE_DATE_UTC, and the former contains more information
> But I care less about this latter point; the main point of this email is to argue for SOURCE_DATE_EPOCH over SOURCE_DATE_UTC (iso8601 locked to "Z" timezone).
I disagree that SOURCE_DATE_UTC provides no benefit over SOURCE_DATE:
at the very least, a program could choose to use it as an
uninterpreted string (similar to the proposed --date option at the
start of this bug, but from the environment rather than a flag).
SOURCE_DATE with an arbitrary offset not so much.
I'm happy to accept SOURCE_DATE, SOURCE_DATE_UTC, SOURCE_DATE_EPOCH or
however. Pick one.
More information about the Reproducible-builds