On April 22, 2021 10:50:34 PM GMT+02:00, Eli Schwartz <eschwartz@archlinux.org> wrote:
On 4/22/21 3:46 PM, anthraxx@archlinux.org wrote:
From: Levente Polyak <anthraxx@archlinux.org>
If a makepkg consumer uses a build wrapper to override compiler flags this may lead to unreproducible packages as there is no way to know which exact files were used for tooling that tries to reproduce said package.
Instead of vendoring the whole used makepkg.conf file into buildinfo, this patch adds two new properties to the .BUILDINFO file named BUILDTOOL and BUILDTOOLVER which by default are simply makepkg's own values. Downstream consumers may override those values: For example in Arch Linux the devtools package can set those values and allow reproducible builds tooling to fetch the appropriate makepkg.conf.
I still believe we should be adding the specific parts of the makepkg.conf which are relevant -- the *FLAGS variables -- and previously submitted a patch to that effect.
If we go the route you're suggesting, then does that mean devtools will install e.g. /usr/share/devtools/oldconfigs/makepkg-{date}.conf or are rebuilder tools supposed to clone devtools and check out the right version?
I personally believe this is a more universal approach with less future maintenance instead of trying to replicate whatever flags get added into every single artifact that gets built. Reproducer tools need to have distro aspects and specific domain knowledge anyway, I believe grabbing a makepkg config file from the source tree based on an identifiable tag is within what's reasonably trivial.
If we're delegating to a buildtool version, should we simplify .BUILDINFO by removing buildenv/options?
I assume this would make sense if we keep this route, In case the approach won't be NACKed I will send a second patch removing the duplicate properties.