[Rpm-maint] [rpm-software-management/rpm] Make rpm builds more reproducible (Issue #2590)

Simon J Mudd notifications at github.com
Mon Aug 7 06:48:16 UTC 2023


In the end **as a first step** I'd like to be able to reproduce the builds as close to what the original builder did.  So I'd like that build to be reproducible in the way referenced in the URL.

- One thing is to record the rpm macro values used during the build process.
- another simple thing would be to record the full list of name / version of rpms installed on the build system.

"rpm builds" are a bit of a pain as often we may use multiple repos. The build environment does not explicitly say where the `BuildRequires:` packages come from, so `rpm` itself is unable to pull down the needed packages in order to trigger the builds.  `yum` or `dnf` could do that but it `rpm` doesn't know about this and the lack of integration between the two sets of tools has always somewhat surprised me though I guess that's a different story and it's water under the bridge now.

I have changed the issue title to **make rpm builds more reproducible** as I think that's what I want and I think that by solving the 2 points above this would help a lot.

I'm also aware that if you run `rpmbuild -bs .....spec` there's no binary build process going on so I'd guess it's quite possible that macro definitions and installed package lists may not actually be useful.  However, if you build source and binary packages together, which I'd assume is the correct thing to do, e.g. `rpmbuild -ba <optional extra macro definitions> whatever.spec` then you will have the information needed and could save this inside the `src.rpm`.

I think this would pretty much help solve my problem.

My second desire, **which is NOT relevant to this issue**, is to then be able to modify the build config or sources or add patches so that the finally built packages provide extra features compared to the originally built packaging, yet if done correctly the result will be compatible with the original packages.  You could think of this along the lines of building extra kernel modules in a separate rpm provided as part of the build process which can be installed and used on the upstream running base kernel.  It's much easier to do this if you can reproduce the upstream build process first.

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

Message ID: <rpm-software-management/rpm/issues/2590/1667282383 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20230806/dca193c0/attachment.html>


More information about the Rpm-maint mailing list