[Rpm-maint] [rpm-software-management/rpm] build: Make sure SOURCE_DATE_EPOCH is in the past (#536)

Jeff Johnson notifications at github.com
Sat Sep 1 19:44:24 UTC 2018



> On Sep 1, 2018, at 2:04 AM, Bernhard M. Wiedemann <notifications at github.com> wrote:
> 
> I'm already producing bit-identical RPMs using the 4 macros documented in
> https://en.opensuse.org/openSUSE:Reproducible_Builds
> So no changes on digests or signatures are needed atm.
> 
> Inaccuracy of $SOURCE_DATE_EPOCH does not matter, as long as it is in the past. Some people always set it to 1 (aka 1970-01-01 00:00:01) and are happy.
> 

If $SOURCE_DATE_EPOCH "does not matter", then any value will do, including a high precision  BUILDTIME tag from the *.src.rpm clamped on all files in packaging.

Distinct advantages to using a high precision build time everywhere include:
* many package rebuilds could be checked for reproducibility without using diffoscope
* clamped file mtimes become more compressible! including in metadata with zchunk.
* the file mtime tag becomes largely vestigial.
* the BUILDTIME becomes useful as a package identifier everywhere, including rebuilds.

While some of these issues are out of scope for your definition of reproducibility, all of the advantages above are closely related to some definition of reproducibility.

The changelog time parsing is/was deliberately sloppy, where 12 noon stood the greatest chance of not causing a date change if/when the timezone was set incorrectly.

Many build systems, and most end-user rebuilds, start from a src.rpm, not from a spec file because the SRPM contains all (at last by design if not in fact) necessary elements for a reproducible build.

POSIX routines to parse date/time are now widely deployed: not true last century.

There comes a time for improving rpm code rather than zombie marching ancient features into the future forevermore: legacy compatibility can be handled with an opt in or out logic to permit distributions the necessary decades to discuss and change as they wish.

>> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub, or mute the thread.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/536#issuecomment-417882743
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20180901/96c29f78/attachment.html>


More information about the Rpm-maint mailing list