Bug#1071246: libglib2.0-dev's python3 dependency alternative is posing challenges to cross building

[Simon McVittie]

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