[Rpm-maint] [rpm-software-management/rpm] Reproducible builds improvements (Discussion #2934)

[Zbigniew Jędrzejewski-Szmek]

> Wait, what? If those differ then the packages do differ, so its not actually bit-per-bit identical. Which is what _I've_ assumed reproducability to mean. This just goes to point out how completely different expectations people have. No wonder having a meaningful discussion about reproducable packages always seems so hard 😄

I wrote a long piece about this [here](https://discussion.fedoraproject.org/t/report-from-the-reproducible-builds-hackfest-during-flock-2023/87469).

> Over the last years I just used `rpm --delsign` to compare with my replication builds and was able to get bit-identical results

Whether we skip some fields when doing a comparison, or take an rpm and strip those fields, and then do the comparison, is just an implementation detail. In practice, users get rpms that are signed. Thus, the format that the users are interested in checking is by definition the signed rpm.

(The other end is interesting too. We generally talk about reproducibility in the sense of starting from srpms. This view originates in the Debian world where the source deb is the only common denominator. Packagers do not have to use git, they do not even have to use a vcs, and people do non-version-controlled binNMUs. Thus, when talking about the whole distro, starting from source debs is the only option. When working with rpms, at the technical level, getting the part from srpm until the binary rpm reproducible is challenging, so it makes sense for us to work on this part in the beginning. But what we actually want in the end is reproducibility of the **full pipeline**, i.e. starting from dist-git. I assume that adding the additional step where we generate the srpm from dist-git will be easy. And in dist-git, we want to have the upstream pristine tarballs, including a signature. In the end, ideally the user would be able to verify that the signed upstream tarball + a specific commit with our spec file leads to the rpms that they download from the mirror, reproducibly.)

> Having a written definition of what "reproducability" means would help driving towards that goal. 

I saw "reproducability" mentioned a few times. I assume it's not a typo, but I have no idea how it's supposed to be different from "reproducibility".

Please see the link above for my definition of "reproducibility".

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2934#discussioncomment-8617435
You are receiving this because you are subscribed to this thread.

Message ID: <rpm-software-management/rpm/repo-discussions/2934/comments/8617435 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20240228/ac4bcaf9/attachment.html>