[Rpm-maint] [rpm-software-management/rpm] RFE: store build reproduction information (Issue #4184)
Panu Matilainen
notifications at github.com
Thu Apr 16 07:04:57 UTC 2026
pmatilai created an issue (rpm-software-management/rpm#4184)
This is obviously drawing the inspiration from https://github.com/rpm-software-management/rpm/pull/1532 - the PR was closed because it stopped moving, not because it was a bad idea. Also it perhaps lacked direction - https://wiki.debian.org/ReproducibleBuilds/BuildinfoFiles is a fine source of inspiration, but rpm is not dpkg, and shooting for some kind of lowest common denominator doesn't seem sensible here.
I think such an initiave should aim to be first-class rpm citizen, with the aim of allowing a rebuild with the exact stored information. There are all sorts of bits and pieces floating around already:
- various build-specific info stored in the src.rpm header (#1241, but arch etc as well)
- build script environment (#3147)
- #3643 will require exporting the full macro context, we might as well store that
Other more or less obvious bits include the list of installed packages and the like.
Besides the what, there's also the question of where. The aforementioned PR stored the data in a binary subpackage, which has it's merits. But then we also have some of the information in src.rpm, and tooling is built around that. The src.rpm itself is a notoriously controversial thing that people expect to be this arch-independent thing, when it isn't that at all, and things like #1241 made it even less so. The src.rpm format as we know it is not fixable in itself - vast amounts of tooling is built on top of this ambiguous construct. It needs to die (long-term): we should instead have an explicitly arch-independent source-archive format, and then an explicitly build-information specific archive that can be used to rebuild a given source-archive.
There's clearly a lot of interest around this area, such as https://github.com/rpm-software-management/rpm/discussions/2851, https://github.com/rpm-software-management/rpm/discussions/4074 and so on. Related items include https://github.com/rpm-software-management/rpm/pull/2762 and https://github.com/rpm-software-management/rpm/issues/3147, and probably more that I don't recall offhand. Tagging in some folks who have shown interest in this area previously, and apologies for anybody I missed - feel free to tag more as appropriate: @mlschroe @bmwiedemann @Conan-Kudo @keszybz @fepitre @DemiMarie @xsuchy @sshedi
This being somewhat open-ended suggests making it a discussion, but past experience has shown those aren't working so well, folks seem to be more willing to participate in a ticket. And, for our own purposes, one cannot assign a discussion so it's easy to lose track as well. We'll use this ticket as the main discussion and add sub-tickets as needed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/4184
You are receiving this because you are subscribed to this thread.
Message ID: <rpm-software-management/rpm/issues/4184 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20260416/fbb9d978/attachment.htm>
More information about the Rpm-maint
mailing list