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

[Jan Zerebecki]

> You've effectively created a situation where your builds are not reproducible outside of your build system with the build system circumstances that created it.

That is incorrect. Pass the same 2 environment variables and it is reproducible. Same as before, just one additional variable.

That the same circumstances are needed was always the case with reproducible builds, the point is to define the circumstances in a machine readable way, so it can be automated.

> From my reading of this, this is a very bad idea, and I'm not sure we should have this. I also think that if this is something openSUSE is going to ship, it should stop saying it's doing reproducible builds.

I discussed this with people at reproducible-builds.org and it was agreed on: https://reproducible-builds.org/docs/source-date-epoch/#interaction-of-source_date_epoch-with-automatic-rebuilds

> (Yes, I'm aware of all the caveats of reproducible builds, please don't add more of them!)

This PR is removing caveats. not adding them. One of the points of it is to make it just work in more cases, even when upstreams are doing things they shouldn't.

@Conan-Kudo From our previous discussions I don't think you understand reproducible builds in the same way as reproducible-builds.org does.
Do you do builds that are reproducible anywhere? My understanding is that Fedora doesn't have enough people with enough of their time working on it. So nobody reproduced even a synthetic package for Fedora for years. The last try I know of was https://reproducible-builds.org/events/hamburg2023/fedora-packages/ . Part of our communication difficulty is that you are talking about a fiction, which is important as a step forward, but not the same as a set of software one can run.

Please suggest solutions, ways towards a concrete implementation or at least scientific arguments instead of unfalsifiable criticism.

> I will also point out that this is premised on some kind of "build counter" property that we don't have.

No it is not, it depends on SOURCE_DATE_EPOCH increasing when the concretely resolved build dependencies change (or any other build input other than the package source changes), which was always the case. That OpenSUSE will use a build counter for that is just one way to do it.

Debian does manual rebuilds and also uses a counter for that, see link above.

One could use the build time of the distributions rpm repository index instead. Or the git commit date from a git repo that defines all the exact packages and their versions of a distribution, which is probably what Nix and Guix are doing.

> It looks like an attempt to eat and keep the cake, and we all know how well that works.

In the digital, especially with cryptographic properties like reproducible build can be used for, that does indeed work, just copy the cake or rebuild it reproducibly.

> Yes, this has the air of digging just deeper into the hole which you should be looking for a way out of instead. The last thing we need on this front is yet more fiddly knobs.

I welcome reducing the amount of fiddly knobs, I thought that was preferred and thus copied the style. Indeed I'd prefer reproducible builds to become the default for rpm, though that is a breaking change, which I think we might want to wait for it to actually work.

@pmatilai Which knobs should I remove for this to be acceptable? Any other suggestions?

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

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