How should setarch work in a multi-arch-Arch world?
This issue might be a little premature since rfcs!32 (merged) hasn't actually progressed to consensus yet, but I'm so excited about it I can't help myself.
I've managed to hack on a fork of devtools to properly create and build inside an ALARM chroot from an x86 host. The changeset is quite minimal, the meat of it is just adding the appropriate pacman.conf (to use the ALARM repos) and makepkg.conf (to use aarch64 GCC cflags/ldflags): https://github.com/armch64/devtools/commit/705891dde76d9e97be241a7d98cccbfc70a017ae
(Yes yes, I know ALARM isn't supported by Arch, let's pretend that RFC0032 has already merged and some brave adventurers are now tasked with hacking a proper officially-unofficial aarch64 port into Arch)
The only other change I needed to make was to sprinkle a bunch of -s
flags throughout makechrootpkg + archbuild.in
to skip the setarch call. I know I could have just hacked "x86_64" into /usr/share/devtools/setarch-aliases.d/aarch64
, but that isn't really a viable solution if one wants to make devtools
work from both an x86_64 host working on an aarch64 chroot (using qemu-user-static) AND a real aarch64 rootfs (running on a real aarch64 machine).
So I have one specific question and one general question that risks devolving into a long discussion/flame-war:
- Would ya'll accept some patches that make it possible to pass
-s
tomakechrootpkg
+archbuild.in
and have that propagate to the various places where that flag is already accepted (arch-nspawn
,archbuild
variants)? - In a future world where an official aarch64/risc-v port exists alongside x86, how would you imagine this setarch stuff to work for qemu-user cross chroots? Would you just prefer not to support that usecase? Or have the x86 variant of the package include the setarch-aliases.d workaround? Or something else?