[Git][reproducible-builds/reproducible-website][master] Misc cosmetic changes to recent SOURCE_DATE_EPOCH addition.

[Chris Lamb (@lamby)]

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


Commits:
eb01fc8c by Chris Lamb at 2024-01-19T11:43:57-08:00
Misc cosmetic changes to recent SOURCE_DATE_EPOCH addition.

- - - - -


1 changed file:

- _docs/source-date-epoch.md


Changes:

=====================================
_docs/source-date-epoch.md
=====================================
@@ -464,50 +464,20 @@ 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.
+## Interaction of `SOURCE_DATE_EPOCH` with automatic rebuilds
+
+When build dependencies change, it is sometimes necessary to rebuild a package without otherwise changing the source. This is especially the case when a security bug is embedded from the build dependency into the build output, as a rebuild is required to fix the security issue. There are, however, many are other situations. Whilst rebuilds of this kind are a manual process in many distributions, some do this automatically.
+
+Debian only performs these rebuilds via a 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 timestamp but a different content. Not increasing the date breaks `rsync` without the `--checksum` option or indeed any transfer/sync/backup process that relies on the `mtime` of files to change to detect underlying content changes. While it is not generally safe to rely on modification times (and thus also not to backup systems without `--checksum`), we should not unnecessarily break things.
+
+OpenSUSE performs such rebuilds automatically and also uses something called "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 its 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, of course, 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
 



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

-- 
View it on GitLab: https://salsa.debian.org/reproducible-builds/reproducible-website/-/commit/eb01fc8c655942e280c2c182c5e5ce44f7d3fcda
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/3ef99979/attachment.htm>