On Mon, 20 May 2024 at 19:45:53 +0200, Helmut Grohne wrote:
> On Fri, May 17, 2024 at 10:42:11AM +0100, Simon McVittie wrote:
> > If someone with more time available for cross-development
> > implemented the cross-exe-wrapper design that I sketched in
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030223#37, then
> > gobject-introspection and libglib2.0-dev would be able to migrate to
> > depending on
> >
> > cross-exe-wrapper | can-run-arch,
> > python3:any,
> >
> > or for backwards-compat maybe
> >
> > cross-exe-wrapper | can-run-arch | qemu-user | qemu-user-static,
> > python3:any,
> >
> > and I think this would also solve the problem?
>
> I think this is technically unsolvable on the package relation level.
> The "can-run-arch" property that you suggest here cannot technically be
> expressed by a dependency relation, because the answer depends on things
> apt doesn't know.
Oh, what I had assumed was that in most cases where there was any doubt,
the cross-exe-wrapper would have to depend on and run qemu-user (at least
after a runtime check for whether it can get away with avoiding qemu). The
cases where cross-exe-wrapper relied on direct execution instead of
qemu or equivalent would be build=foo, host=foo for all values of foo,
plus probably build=amd64, host=i386 as a common special case.
I'd been thinking of can-run-arch as an extension point that a sysadmin
could set up with equivs (for example to represent the use-case you
described where qemu-user-static is set up with binfmt_misc outside the
chroot), rather than something that would exist in the archive; I'd assumed
that cross-exe-wrapper would be the automatic interface.
Thinking more about this, though, I think the cross-exe-wrapper itself
could have the same problem that you've described in libglib2.0-dev:
on build=amd64 and (let's say) host=riscv64, if we had something like
Package: libglib2.0-dev
Architecture: riscv64
Multi-Arch: same
Depends: cross-exe-wrapper | can-run
Package: cross-exe-wrapper
Architecture: riscv64
Multi-Arch: same
Depends: cross-exe-wrapper-riscv64-linux-gnu
Package: cross-exe-wrapper-riscv64-linux-gnu
Architecture: riscv64
Multi-Arch: ??? # no? foreign? allowed?
# trivial wrapper, runs binary directly
Package: cross-exe-wrapper-riscv64-linux-gnu
Architecture: amd64
Multi-Arch: foreign
Depends: qemu-user
# non-trivial wrapper, runs via qemu
then I think it would be valid (but definitely undesired!) for
apt to satisfy cross-exe-wrapper's dependency by installing
cross-exe-wrapper-riscv64-linux-gnu:riscv64, which of course we would
be unable to run. So this is another place where ideally we would like
to be able to depend on "cross-exe-wrapper-riscv64-linux-gnu:runnable"
or some similar syntax that doesn't yet exist.
> * We cross build from amd64 to x32, but the kernel does not enable the
> x32 abi.
It's common to do that (and I believe x32 is runtime-disabled on Debian
kernels by default to limit attack surface), so I would have assumed
we'd want to make cross-exe-wrapper pull in qemu-user when build=amd64,
host=x32; but if it can avoid actually needing to run it, with a runtime
check like the ones in the cross g-i tools, then so much the better.
> * We cross build from amd64 to m68k and have externally installed
> qemu-user-static as we mostly care about speeding up builds rather
> than doing "pure" cross builds.
In this case it would be harmless to install qemu-user into the chroot
(a bit of a waste of I/O but no real harm), and it hardly matters whether
we use the host system's qemu or the chroot's, as long as all the necessary
tools are runnable.
> * We cross build for i386 from amd64 and disable the i386 kernel ABI
> via seccomp-bpf to simulate a QA cross build.
My inclination would be to say that's too artificial to be something
that we'd be willing to pay a price to support (the price is #1070773),
but you know better than I do.
> * Some arm64 CPUs can run arm32, but not all.
As with x32 on amd64, the wrapper would have to pessimistically assume
that we do need qemu-user (optionally with a runtime check to shortcut
to running the binary directly if we can).
smcv
