[Reproducible-commits] [source-date-epoch-spec] 01/02: factor away some redundancy in the parts about setting SOURCE_DATE_EPOCH yourself

Ximin Luo infinity0 at debian.org
Fri Aug 28 18:30:10 UTC 2015


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

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

commit e049e520cd478f3efe585a3177829f9657d972f5
Author: Ximin Luo <infinity0 at debian.org>
Date:   Fri Aug 28 20:29:17 2015 +0200

    factor away some redundancy in the parts about setting SOURCE_DATE_EPOCH yourself
---
 source-date-epoch-spec.xml | 30 +++++++++++++++---------------
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/source-date-epoch-spec.xml b/source-date-epoch-spec.xml
index b80f3de..d6e8bdf 100644
--- a/source-date-epoch-spec.xml
+++ b/source-date-epoch-spec.xml
@@ -134,7 +134,7 @@
 			embed a build-time timestamp into generated files.
 		</para>
 		<para>
-			As the current time is implicitly unstable across
+			As the current time is inherently unstable across
 			different builds, this results in the generated
 			binaries containing different contents and are thus
 			unreproducible. This embedding occurs in a wide variety
@@ -248,15 +248,6 @@
 			time, but this is not necessary for the purposes of this
 			specification.
 		</para>
-		<para>
-			Upstream build processes MAY attempt to set this variable
-			for child processes to consume, for example by reading
-			the time of the latest VCS commit or filesystem entry if
-			there are uncommitted changes. However, they MUST NOT do
-			this if the variable is already set, for example by a
-			parent process such as distribution build scripts, or by
-			the user themselves.
-		</para>
 		<warning>
 			<para>
 				In addition, care should be taken to avoid timezone
@@ -269,16 +260,25 @@
 			</para>
 		</warning>
 		<para>
+			Upstream build processes MUST NOT overwrite this variable
+			(e.g. for child processes to consume) if it is already
+			set (e.g. by a parent process or the user themselves).
+		</para>
+		<para>
 			If the value is missing or empty, the upstream build
 			process chooses its own behaviour; this situation is
 			indistinguishable from one that is not following this
 			specification. However, we RECOMMEND that the behaviour
 			should more closely approximate the date of the last
-			modification to the source code. This may be detected
-			automatically if the source is on a developer's machine
-			or from VCS, or hard-coded into an official release
-			tarball; falling back to the "current" date and time of
-			the build is NOT RECOMMENDED.
+			modification to the source code. Falling back to the
+			"current" date and time of the build is NOT RECOMMENDED.
+			For example, the upstream build process MAY attempt to
+			automatically detect an appropriate value to set this
+			variable to, by reading the time of the latest VCS commit
+			or filesystem entry if there are uncommitted changes, or
+			from a hard-coded value in an official release tarball.
+			Child processes may then consume this variable as if
+			they were following this specification themselves.
 		</para>
 		<para>
 			If the value is malformed, the upstream build process

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



More information about the Reproducible-commits mailing list