[Rpm-maint] [rpm-software-management/rpm] Reproducible builds improvements (Issue #2894)

Jan Zerebecki notifications at github.com
Wed Feb 21 10:49:48 UTC 2024


I think @pmatilai meant having %source_buildtime with constants of either `SOURCE_DATE_EPOCH`, `SOURCE_DATE_EPOCH_MTIME`, `macro` or `clock`? I'm ok with that.

My preferred way would be as few macros or settings, but that is not as backwards compatible. Only reproducible builds. Build host field in rpm files is always set to `reproducible`. Build fails if neither last changelog date nor $SOURCE_DATE_EPOCH can be found to set build time. File mtimes are always set, either to build time or if $SOURCE_DATE_EPOCH_MTIME exists to that, no clamping. (SOURCE_DATE_EPOCH_MTIME is a replacement for the name NEW_SOURCE_DATE_EPOCH from my previous version of that patch, to be more descriptive. It also means we do not need to switch OLD and NEW around.)

My understanding is that @mlschroe prefers to have $SOURCE_DATE_EPOCH_MTIME set the build time and if it is set rpm would ignore but pass through $SOURCE_DATE_EPOCH. That has the downside that it is conceptually more complicated. It also doesn't nest cleanly, while we could more easily ignore mtimes in archives in a nested way, say for an rpm containing a zip, where a build picked up $SOURCE_DATE_EPOCH_MTIME for the zip mtimes. If a build picks up $SOURCE_DATE_EPOCH_MTIME and puts it in the content, say a build time field in an elf executable, we have the same problem again. To avoid that problem we can outright prevent nesting by having rpm copy $SOURCE_DATE_EPOCH_MTIME to the build time and unset it. I'm not sure if this is a good idea. The downside is that any nested archives can not be fixed in the same way, if the non-incremented mtimes in those become a problem. @mlschroe What do you think?

We should not use clamping mtimes, outright setting them has fewer possibilities for errors (like incorrect clock). Always setting the mtimes to build time like detailed above and having no setting for it, might work in practice without breaking anything. @pmatilai However are you ok to make such a change in a normal rpm release?

Same question for the other changes?

If only OpenSUSE is using those settings that would make at least removing those we stop using easy. Is anyone else using any?

Meanwhile testing this in OpenSUSE is making progress, I hope I fixed the last rpm that has had no changelog.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2894#issuecomment-1956381730
You are receiving this because you are subscribed to this thread.

Message ID: <rpm-software-management/rpm/issues/2894/1956381730 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20240221/21df1c97/attachment-0001.html>


More information about the Rpm-maint mailing list