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

[Levente Polyak]

On April 22, 2021 10:50:34 PM GMT+02:00, 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?

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.