On 4/22/21 3:46 PM, [email protected] wrote: > From: Levente Polyak <[email protected]> > > 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 <[email protected]>
> ---
> 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
OpenPGP_signature
Description: OpenPGP digital signature
