[Rpm-maint] [rpm-software-management/rpm] support reproducible automatic rebuilds (PR #2880)

[Zbigniew Jędrzejewski-Szmek]

I read this proposal when the ticket was initially created, and I didn't find it convincing, and now, a few weeks later, I still don't.

This is a very complex solution to a very specific problem. It is very narrowly tailored to the specific details of the build system and package delivery system that you have, and makes very strong assumptions about which mtime should be used where.  Right now we have the concept of the $SOURCE_DATE_EPOCH, and it is a *single* timestamp that says "this is when the build happened", and both the packager and the user can understand it. This means that the same value is used in many places: embedded build metadata, headers and footers in build docs, the changelog, file mtimes or delivered files, etc. With the patch, we have two timestamps, with ad-hoc rules which to use where. Without considering further technical details, I think this increased complexity would never be worth it.

At a more technical level, I think in particular this would break Python .pyc file caching: Python uses cache invalidation where it compares the mtime on the .py file with the timestamp-of-the-original-py-file embedded in the .pyc file. For packages, the .pyc file is created during build and stored in the package. IIUC, you want to use $OLD_SOURCE_DATE_EPOCH for "build scripts", i.e. .pyc files would embed $OLD_SOURCE_DATE_EPOCH, but actually deliver files with mtimes set to (new) $SOURCE_DATE_EPOCH. This means that Python would consider the .pyc file stale and always try to rebuild it.

(If, OTOH, you use the mtimes with $OLD_SOURCE_DATE_EPOCH in delivered files, then the user loses an important property that the mtime of compiled files corresponds to the package build.)

> OpenSUSE does not change the changelog for the rebuild

I think this is a fundamental error. You're doing a rebuild because something *important* changed. When the user gets this newly-built package, they really should know that this is an updated version with the *important* thing. So if there's a %changelog at all, stuff like version bumps and rebuilds for important environment changes are the foremost things to put there. But if the changelog changes, the package is not the same, and in general, I think it doesn't make sense to twist everything to try to avoid updating the package.

I would suggest a different approach: if you have the environment change, do a *test rebuild* with no changelog change and the original $SOURCE_DATE_EPOCH. If the result is bit-for-bit identical, record this in a log somewhere and throw away the build, since the users don't need to update. If the result shows any changes, record a changelog entry and rebuild with the new $SOURCE_DATE_EPOCH and push that out to users.

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

Message ID: <rpm-software-management/rpm/pull/2880/c1966099057 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20240227/8067bbb2/attachment-0001.html>