On Thu, 22 Apr 2021 at 21:50, 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?
Before I f*ked it up and removed it, repro was using an equivalent to: pacman -S devtools cp /usr/share/devtools/makepkg-x86_64.conf /etc/makepkg.conf
If we're delegating to a buildtool version, should we simplify .BUILDINFO by removing buildenv/options?
It's a possibility. AFAICT Levente's solution is more scalable and since it won't require pacman release, easier/quicker to turnaround. While I can see value in both solutions, the pragmatist in me would opt for Levente's patch, while the perfectionist your proposal. -Emil