[Git][reproducible-builds/reproducible-website][master] add SOURCE_DATE_EPOCH interaction with rebuilds

[Chris Lamb (@lamby)]

Chris Lamb pushed to branch master at Reproducible Builds / reproducible-website


Commits:
3a3988bf by Jan Zerebecki at 2024-01-19T19:39:03+00:00
add SOURCE_DATE_EPOCH interaction with rebuilds

- - - - -


1 changed file:

- _docs/source-date-epoch.md


Changes:

=====================================
_docs/source-date-epoch.md
=====================================
@@ -464,6 +464,51 @@ If for some reason you're still conflicted on suddenly changing the meaning of y
 
 OTOH, one alternative we can agree with, that also avoids `SOURCE_DATE_EPOCH`, would be to translate the static instruction "get_current_time()" from the input format to ''an equivalent instruction'' in the output format, if the output format supports that.
 
+## Interaction with automatic rebuilds
+
+When build dependencies change it is sometimes necessary to rebuild a package
+without otherwise changing the source. Especially when a security bug is
+embedded from the build dependency in the build output then the rebuild is
+needed to fix the security issue, but there are other situations. While this is
+a manual process in many distributions, some do this automatically.
+
+Debian does this only on manual developer request called binary non-maintainer
+upload (binNMU). For this `SOURCE_DATE_EPOCH` is incremented by 1 to avoid
+creating a situation where two build results contain files with the same name
+and the same modification time stamp but a different content. Not increasing
+the date breaks rsync without --checksum or anything else that relies on mtime
+of files to detect changes. While it is not generally safe to rely on mtimes
+and thus also not to backup systems without --checksum, we should not
+unnecessarily break things.
+
+OpenSUSE does such rebuilds automatically and also uses build tree pruning.
+Build tree pruning is to discard the output when it is the same and thus not
+trigger such rebuilds on packages that build depend on the discarded output.
+Normally this works, but if a build e.g. embeds `SOURCE_DATE_EPOCH` in the
+output, then the output changes every time such a rebuild happens, which can be
+very often. This is to be avoided as updating packages without necessity is too
+expensive.
+
+The correct solution would be to never embed `SOURCE_DATE_EPOCH` as so far no
+use case was found were something else is not better, like instead embed a
+major version number. However convincing everyone and changing every instance
+of this is an impractical task.
+
+The following achieves both detecting rebuilds that did not change despite a
+changed build dependency and having an incremented mtime on files
+in the output:
+
+* Use the old `SOURCE_DATE_EPOCH` that was not incremented for the inner build
+  script.
+* Use the incremented `SOURCE_DATE_EPOCH` for the outer build script which uses
+  it to set the file date after the inner build script is done.
+* Instead of clamping the file date to `SOURCE_DATE_EPOCH`, set it exactly.
+  This avoids bugs where one of the inner build scripts sets the file date to
+  something earlier, causing two builds to output a file with same date and name,
+  but different content.
+* Ignore the file date when comparing build output to decide whether to discard
+  for build tree pruning.
+
 ## History and alternative proposals
 
 [1](https://lists.alioth.debian.org/pipermail/reproducible-builds/Week-of-Mon-20150608/001823.html) and the surrounding messages describe the initial motivation behind this, including an evaluation of how different programming languages handle date formats.



View it on GitLab: https://salsa.debian.org/reproducible-builds/reproducible-website/-/commit/3a3988bfdf5428021ef29c2fa60c093610abf993

-- 
View it on GitLab: https://salsa.debian.org/reproducible-builds/reproducible-website/-/commit/3a3988bfdf5428021ef29c2fa60c093610abf993
You're receiving this email because of your account on salsa.debian.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.reproducible-builds.org/pipermail/rb-commits/attachments/20240119/204c401f/attachment.htm>