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

[Eli Schwartz]

On 4/22/21 6:42 PM, Emil Velikov wrote:
> 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

This isn't inherently wrong though. That is what makerepropkg does too
(it ships with devtools and inits a chroot using devtools).

Though it does then add

    printf 'OPTIONS=(%s)\n' "${buildopts[*]@Q}"
    printf 'BUILDENV=(%s)\n' "${buildenv[*]@Q}"

to the makepkg.conf (extracted from .BUILDINFO)

>> 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.

I simply don't understand what you're trying to say, since both do
require pacman release. How else will buildtool get set?

-- 
Eli Schwartz
Bug Wrangler and Trusted User

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/pacman-dev/attachments/20210422/279e4f6d/attachment.sig>