On Thu, 22 Apr 2021 at 21:50, Eli Schwartz <[email protected]> wrote: > > On 4/22/21 3:46 PM, [email protected] wrote: > > From: Levente Polyak <[email protected]> > > > > 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
