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

Simon J Mudd notifications at github.com
Fri Aug 4 12:02:48 UTC 2023


I think you misunderstand. If you build for multiple OS versions. e.g. RHEL 7..9 then dependencies are different, so you can't explicitly as rpm works at the moment configure all the dependencies at the same time. This is done by adding additional macro processing to either be told the OS to build for .e.g. Oracle community MySQL rpms tend to use `--define 'rh7 1'` or `--define 'rh8 1'` or `--define 'rh9 1'` to provide the "hints" to build the package. This can't be done during the build process as `BuildRequires:` or `Requires:` tags are "static" by this time (evaluated prior to the build by `rpmbuild`.

Yet to be reproducible you need to know which macros were provided by the user or at least are "not part of the base rpm/build setup" and therefore are "user configurable". Without that you may not be able to determine exactly the same "input parameters" to re-build a package in the same was as the original packager. Similarly if I want to patch this package with different/extra functionality I can not be sure that my build will represent a consistent change against the original sources, and thus the whole premise of repeatable builds falls apart.

My question therefore was whether there are any plans to ensure that a built src rpm could be configured to include any rpmbuild time command line macros as metadata so that I can use that in theory to reproduce the build process faithfully.

Reason for this coming up. I'm having problems reproducing the builds because it looks like the original build environment used by the original packagers  may not be "pristine" to fix one specific build issue I had to build add some symlinks , e.g. https://github.com/sjmudd/mysql-rpm-builder/blob/main/config/prepare__centos.8__8.0.33.sh#L44-L50 to setup the OS in a way which the build process would complete without errors.  That's clearly a very obscure example but it's real.

So I'm looking at ways to be make it easier for the rpm packaging to be configured in such a way that issues such as this can be avoided and having a "suitable spec file" I really can repeatably build from scratch successfully.

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

Message ID: <rpm-software-management/rpm/issues/2590/1665499416 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20230804/4c36cde5/attachment-0001.html>


More information about the Rpm-maint mailing list