[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