On 4/22/21 3:46 PM, anthraxx@archlinux.org wrote:
From: Levente Polyak <anthraxx@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? If we're delegating to a buildtool version, should we simplify .BUILDINFO by removing buildenv/options?
Signed-off-by: Levente Polyak <anthraxx@archlinux.org> --- scripts/makepkg.sh.in | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index 92cb6398..e58edfa1 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -651,6 +651,8 @@ write_buildinfo() { write_kv_pair "builddate" "${SOURCE_DATE_EPOCH}" write_kv_pair "builddir" "${BUILDDIR}" write_kv_pair "startdir" "${startdir}" + write_kv_pair "buildtool" "${BUILDTOOL:-makepkg}" + write_kv_pair "buildtoolver" "${BUILDTOOLVER:-$makepkg_version}" write_kv_pair "buildenv" "${BUILDENV[@]}" write_kv_pair "options" "${OPTIONS[@]}"
-- Eli Schwartz Bug Wrangler and Trusted User