Hardcoded x86_64 in makerepropkg
`makerepropkg` has a hardcoded "x86_64", so fails to run on other [unofficial] architectures, because it tries to use an x86_64-specific makepkg config, which overrides CARCH=x86_64. I tried addressing it with this simple patch: diff --git a/src/makerepropkg.in b/src/makerepropkg.in index b271f25..846af06 100644 --- a/src/makerepropkg.in +++ b/src/makerepropkg.in @@ -92,7 +92,7 @@ get_makepkg_conf() { return 1 fi msg2 "using makepkg.conf from ${fname}" - bsdtar xOqf "${buildtool_file/file:\/\//}" usr/share/devtools/makepkg-x86_64.conf > "${makepkg_conf}" + bsdtar xOqf "${buildtool_file/file:\/\//}" "usr/share/devtools/makepkg-$CARCH.conf" > "${makepkg_conf}" return 0 } This half-works, but the arch derivates still needs to ship a custom `devtools` package with their own `makepkg-$CARCH.conf`. Usually, the only thing that really needs to be changed in the per-architecture custom makepkg.conf is CARCH and CHOST. This is still not ideal, and sounds like it could be refined further into something simpler. The .BUILDINFO file specifies the devtools version originally used, so that makerepropkg can download that specific version and use the right makepkg.conf file for the rebuild. It would be much simpler dump all variables from `makepkg.conf` into .BUILDINFO at build-time, and use these directly when rebuilding to test reproducibility. Instead of the package indicating the version of devtools contains its build configuration, the package just includes the build configuration directly. This removes one level of indirection. This approach would also allow checking the reproducibility of packages that were built with slight different settings (including those built by derivates/unofficial platforms). Any thoughts on this? Side note: the above patch might still have value if merged, at least in the short term. -- Hugo Osvaldo Barrera
participants (1)
-
Hugo Osvaldo Barrera