[pacman-dev] [PATCH] makepkg: add tool details to buildinfo to aid determining flags

Emil Velikov emil.l.velikov at gmail.com
Thu Apr 22 22:42:16 UTC 2021


On Thu, 22 Apr 2021 at 21:50, Eli Schwartz <eschwartz at archlinux.org> wrote:
>
> On 4/22/21 3:46 PM, anthraxx at archlinux.org wrote:
> > From: Levente Polyak <anthraxx at 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


More information about the pacman-dev mailing list