Re: mapping from debian arch to qemu arch
18.04.2023 14:56, Johannes Schauer Marin Rodrigues пишет:
On the other hand, there are still some rough edges. Theoretically, this
simplification could be done to autokpgtest but the package only Suggests
qemu-system so it's not possible to enforce the minimum version constraint:
https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/223/diffs
Well, autopkgtest itself does not depend on any qemu stuff for obvious
reasons. I think it should not, instead, whatever setup is done to
autopkgtest which enables testing in qemu, should have the deps.
You don't need versioned dependency on qemu-system though, you can use
qemu-system-any (new in next debian release) or qemu-system-arm64 for
example.
Either way, those dependencies are.. difficult, since only the end-user
actually know which arches/configuration they need.
Another problem is, that this mapping only lives in the qemu-system-* packages.
My package mmdebstrap also needs a mapping from Debian architecture to Qemu
architecture but it only needs qemu-user installed because instead of running a
full system emulation, it makes use of binfmt_misc support. So if I wanted to
drop the map from mmdebstrap I would have to add a Depends on qemu-system,
which would be very wasteful. Is there a better solution for packages that only
need qemu-user and not qemu-system?
qemu-user works in a different way. You don't run qemu-$arch directly, instead,
you rely on binfmt support which is configured once qemu-user is installed.
Running qemu-$arch directly gives you nothing, as it only works before the
next fork/exec, where you have to rely on binfmt again.
I'm talking about qemu-user-STATIC here (qemu-user as the name of qemu feature,
like there's qemu-system vs qemu-user (vs qemu-bsd-user)). Only the static
interpreter works with binfmt_misc and chroots, since only statically-
linked binary can be pre-loaded by the kernel (the F binfmt-misc flag),
dynamic binary needs other components like libc.so.6 which will be read
at exec time (in whatever namespace it happens to be), not when the
exec format is loaded.
So basically, you don't need any explicit mapping for qemu-user at all,
unless you need to copy the right qemu-user[-static] binary into the chroot,
which isn't needed since introduction of the F flag.
Maybe one day, we'll split qemu-user-static into subarchitectures, and
you'll have to worry.. ;)
Thanks,
/mjt
Reply to: