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

[Eli Schwartz]

On 4/22/21 6:04 PM, Levente Polyak wrote:
> On April 22, 2021 10:50:34 PM GMT+02:00, Eli Schwartz <eschwartz at archlinux.org> wrote:
>> 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. 

It's a specific solution, instead of a generic solution. And I don't
believe it is a maintenance burden to maintain a list of flag types
which makepkg.conf and the prepare_buildenv() function don't see much
churn on anyway. (The number of flag types has remained essentially
constant for C/C++ until I added rust support.)

It means that in order to create a package that can be reproduced, you
need/are expected to add additional stuff to the environment -- if
BUILDTOOL is unset, we might as well stop setting SOURCE_DATE_EPOCH,
touch'ing files to a reproducible timestamp in create_package or after
extract_sources, etc. Because if the build tool is just "makepkg", we're
saying "no, this package is not expected to be reproducible". Right?


We could even be daring and stop creating the .BUILDINFO file either.

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

Then makerepropkg which is a release version of devtools, needs to know
how to retrieve the development version of itself in order to operate.
Which seems backwards.

I know that repro needs to bootstrap itself from any OS, so it does more
complicated steps including cloning sources, syncing makepkg.conf from
devtools, etc. Once you're already doing that, "clone devtools and find
the configuration file from a specific release" sounds less complicated
and more like something you're already doing.

And we will likely start seeing automated build tools (CI/CD release
pipelines?) that are not devtools, but use the devtools makepkg.conf,
call themselves "devtools" for compatibility purposes. Because the
buildtool is not actually relevant, only the makepkg.conf it uses is
relevant, but... people wanna message which makepkg.conf they're using
so they can demonstrate their supply chain security. And docker builds
shouldn't be measurably different from systemd-nspawn ones!

If this ends up happening, we'll know we have reinvented the browser
user agent...

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


-- 
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/d1a0def1/attachment-0001.sig>