[Reproducible-commits] [source-date-epoch-spec] 01/01: Just throw this in here so I can work on it $elsewhere

[Chris Lamb]

This is an automated email from the git hooks/post-receive script.

lamby pushed a commit to branch master
in repository source-date-epoch-spec.

commit d2825ca78db58e8356103a534c2699a6b450b567
Author: Chris Lamb <lamby at debian.org>
Date:   Thu Aug 27 01:05:41 2015 +0200

    Just throw this in here so I can work on it $elsewhere
---
 source-date-epoch-spec.xml | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/source-date-epoch-spec.xml b/source-date-epoch-spec.xml
index 04b9346..ba1ec71 100644
--- a/source-date-epoch-spec.xml
+++ b/source-date-epoch-spec.xml
@@ -118,6 +118,29 @@
 		when they were built.
 	</para>
 	<para>
+		There are several rationales for embedding the build date:
+	</para>
+	<itemizedlist>
+	<listitem><para>
+		FIXME: it gives "some indication" of the age of the software.
+		However, this becomes basically redundant with reproducible
+		builds, as the whole point of reproducible builds is that the
+		build result will be exactly the same no matter when it was
+		built. To phrase this differently: if the only difference in
+		the build result is the embedded build date, then this
+		difference is meaningless and should be removed, or replaced
+		with a meaningful date.
+	</para></listitem>
+	<listitem><para>
+		FIXME: it gives "some indication" of the build environment
+		(e.g. age of the build dependencies?). But with reproducible
+		builds, there is no need to guess which build environment has
+		been used, based on a timestamp. To allow users to reproduce
+		binaries, the build environment is either known in advance, or
+		recorded (e.g. in .buildinfo files).
+	</para></listitem>
+	</itemizedlist>
+	<para>
 		FIXME: why timestamps become meaningless and/or misleading if
 		the software is reproducible.
 	</para>

-- 
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/reproducible/source-date-epoch-spec.git