On Sun, 16 Apr 2023 at 00:25, John Gilmore <g...@toad.com> wrote: > > James Addison via rb-general <rb-general@lists.reproducible-builds.org> wrote: > > In general, we should be able to > > pick two times, "s" and "t", s <= t, where "s" is the > > source-package-retrieval time, and "t" is the build-time, and using > > those, any two people should be able to create exactly the same > > (bit-for-bit) documentation. I think that SOURCE_DATE_EPOCH generally > > refers to "t". > > I think that SOURCE_DATE_EPOCH generally refers to the check-IN time of > each of the source package(s) being rebuilt. You can retrieve the > packages anytime later than that, and you can do the build at any time > later, and SOURCE_DATE_EPOCH should not change (and the built binaries > and docs should also not change).
When the goal is to build the software as it was available to the author at the time of code commit/check-in - and I think that that is a valid use case - then that makes sense. (this ignores a subtlety in the hypothetical case where multiple independent software authors could be tasked with writing to a specification but without access to each others' source dependencies -- in that case there is no notion of the "software as it was available to [each] author". using FOSS licensing and publication solves most of that problem, excepting situations where individual authors are out-of-contact during software development) Inverting the question somewhat: if a single source-base is rebuilt using two different SOURCE_DATE_EPOCH values (let's say, 1970-01-01 and 2023-04-18), then what are expected/valid differences in the resulting output?