groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Groff] Reproducible dates in HTML/PDF/PS output files?


From: Colin Watson
Subject: Re: [Groff] Reproducible dates in HTML/PDF/PS output files?
Date: Thu, 5 Nov 2015 11:34:19 +0000
User-agent: Mutt/1.5.23 (2014-03-12)

Here's an updated patch for this issue.  The difference relative to my
previous patch is that, rather than taking an environment variable to
disable timestamp output altogether, this takes an environment variable
to force a specific time: this is intended to be used by build systems
to e.g. ensure that all documents produced by a given build have a
creation date corresponding to the changelog date of the overall
package, rather than whatever time the build system happened to run.

Notwithstanding Werner's comments, I think that an environment variable
is a clearly better approach to this, because it's much easier to
arrange for it to be passed through build systems.  But I hope that
switching to the timestamp-based variable means that it's unlikely to be
set permanently in users' environments.  Also, SOURCE_DATE_EPOCH is an
emerging standard which is supported in an increasing number of other
packages, which means that build systems only need to set one variable
rather than kludging around things in a dozen different places.

The reason why filtering PDF output and the like is an inferior
solution, even though it's certainly possible (strip-nondeterminism
etc.; https://reproducible-builds.org/docs/timestamps/), is that it's
much more complicated and less transparent.  With a reproducible build
toolchain it is possible to build an entire package multiple times on
entirely different systems and get a bitwise-identical .deb; if you're
relying on postprocessing then it's much less obvious that nothing else
has sneaked in and you need a complicated pile of stuff to unpack two
packages and do a deep (possibly recursive!) comparison of files within
them.  Yes, we did without this for 20+ years, and it's not absolutely
the end of the world not to have it, but that doesn't mean it isn't
useful to work on it now.

More details on SOURCE_DATE_EPOCH (and there are many other useful
things on the same site):

  https://reproducible-builds.org/specs/source-date-epoch/

-- 
Colin Watson                                       address@hidden

Attachment: 0001-Implement-SOURCE_DATE_EPOCH-for-reproducible-builds.patch
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]