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