Hello!
TL;DR: skip to The Question: below.
QEMU system mode is a whole-machine emulator which is able to run
virtual machines of various architectures. Here's the current list
of emulators on amd64:
total 417456
-rwxr-xr-x 1 mjt mjt 24042800 Apr 18 20:50 qemu-system-aarch64*
-rwxr-xr-x 1 mjt mjt 12696784 Apr 18 20:50 qemu-system-alpha*
-rwxr-xr-x 1 mjt mjt 21832624 Apr 18 20:50 qemu-system-arm*
-rwxr-xr-x 1 mjt mjt 7887152 Apr 18 20:50 qemu-system-avr*
-rwxr-xr-x 1 mjt mjt 8045936 Apr 18 20:50 qemu-system-cris*
-rwxr-xr-x 1 mjt mjt 12768624 Apr 18 20:50 qemu-system-hppa*
-rwxr-xr-x 1 mjt mjt 19455408 Apr 18 20:50 qemu-system-i386*
-rwxr-xr-x 1 mjt mjt 14768816 Apr 18 20:50 qemu-system-loongarch64*
-rwxr-xr-x 1 mjt mjt 9510992 Apr 18 20:50 qemu-system-m68k*
-rwxr-xr-x 1 mjt mjt 8065904 Apr 18 20:50 qemu-system-microblaze*
-rwxr-xr-x 1 mjt mjt 8065904 Apr 18 20:50 qemu-system-microblazeel*
-rwxr-xr-x 1 mjt mjt 14265072 Apr 18 20:50 qemu-system-mips*
-rwxr-xr-x 1 mjt mjt 14425424 Apr 18 20:50 qemu-system-mips64*
-rwxr-xr-x 1 mjt mjt 16435440 Apr 18 20:50 qemu-system-mips64el*
-rwxr-xr-x 1 mjt mjt 14256880 Apr 18 20:50 qemu-system-mipsel*
-rwxr-xr-x 1 mjt mjt 7907664 Apr 18 20:50 qemu-system-nios2*
-rwxr-xr-x 1 mjt mjt 12441616 Apr 18 20:50 qemu-system-or1k*
-rwxr-xr-x 1 mjt mjt 16583760 Apr 18 20:50 qemu-system-ppc*
-rwxr-xr-x 1 mjt mjt 17534000 Apr 18 20:50 qemu-system-ppc64*
-rwxr-xr-x 1 mjt mjt 16277552 Apr 18 20:50 qemu-system-riscv32*
-rwxr-xr-x 1 mjt mjt 16310288 Apr 18 20:50 qemu-system-riscv64*
-rwxr-xr-x 1 mjt mjt 7857424 Apr 18 20:50 qemu-system-rx*
-rwxr-xr-x 1 mjt mjt 10151728 Apr 18 20:50 qemu-system-s390x*
-rwxr-xr-x 1 mjt mjt 12671152 Apr 18 20:50 qemu-system-sh4*
-rwxr-xr-x 1 mjt mjt 12679344 Apr 18 20:50 qemu-system-sh4eb*
-rwxr-xr-x 1 mjt mjt 8779312 Apr 18 20:50 qemu-system-sparc*
-rwxr-xr-x 1 mjt mjt 13066576 Apr 18 20:50 qemu-system-sparc64*
-rwxr-xr-x 1 mjt mjt 7986096 Apr 18 20:50 qemu-system-tricore*
-rwxr-xr-x 1 mjt mjt 19507280 Apr 18 20:50 qemu-system-x86_64*
-rwxr-xr-x 1 mjt mjt 7819376 Apr 18 20:50 qemu-system-x86_64-microvm*
-rwxr-xr-x 1 mjt mjt 16713616 Apr 18 20:50 qemu-system-xtensa*
-rwxr-xr-x 1 mjt mjt 16557808 Apr 18 20:50 qemu-system-xtensaeb*
Some years ago we had a single qemu-system package which included
all the above (actually a bit less than that, there was no arm64,
loongarch64 or microvm parts). All this stuff requires various
firmware packages to be useful, - such as various openbios variants,
u-boot, x86 firmware, slof, and a few more. Due to the large list
of dependencies, and large size of qemu-system package, I've split
it into multiple per-architecture-family subpackages such as
qemu-system-x86 and qemu-system-ppc. This was a trade-off between
large number of packages and a large package with big set of deps.
Some emulators went to qemu-system-misc subpackage (which grew
larger with time).
Later on, the external dependencies has been removed (quite some
firmware is now built from qemu source package). And qemu started
being used much more widely due to various debian properties being
added such as multiarch, cross-compilation efforts, and others.
More packages started using qemu-system in various ways. But due
to this strange split, the dependencies aren't usually right, and
it's at least difficult to make them right.
For example, qemu-system provides kvm mode on many platforms,
which does not enable CPU emulation, using native CPU and hence
native execution speed. This mode can be used, for example, for
isolation, for more extensive testing of packages and for many
other things besides the traditional VM usages.
So it looks like now it's a time to do something with all this.
In the recent upload (to -experimental due to freeze), I've added
debian naming for packages and binaries, for example there's now
qemu-system-amd64 which is a symlink to qemu-system-x86_64 - this
way it's possible to depend or use qemu-system-${DEB_HOST_ARCH}
directly without having a translation table. It should already
help some usages to find the right package and the right binary.
The Question: how to rearrange the qemu-system-foo packages best?
I'm thinking about having two packages here instead of many:
it is qemu-system-native and qemu-system-emu. The first one
will have qemu-system binaries for the native CPU/arch, like
what qemu-system-x86 provides for x86/amd64, or qemu-system-ppc
for powerpc/ppc64 platform, also like ubuntu-only qemu-system-s390x
provides on s390x. And the other to contain all the emulators
for all other platforms, and depend on -native for various
common modules and whatnot.
Note that -native does not necessary have kvm mode, since it is
not available on all platforms, - so for some (eg sparc) it
will still be emulated. So maybe it shouldn't actually exist
on those platforms.
Another variation is to have qemu-system-kvm package which
provides native kvm-accelerated mode, plus qemu-system-emu
package with anything else. qemu-system-kvm will not be available
at all on platforms not supporting kvm (or we'll have a dummy
package there).
And the 3rd variant is to just merge everything back into single
qemu-system package the way it has been a few years back (now
with greatly reduced set of dependencies but with grown size).
This is - hopefully - the long-term goal, because upstream is
slowly thinking about building qemu-system as a single binary
which provides emulation of everything available, - obviously
we won't try to split such binary into multiple packages :)
But this goal seems to be too far in the future to be plannable.
Without such merge into single binary, the package will be large
(see full list of emulator binaries above), but hdd space is
much cheaper nowadays..
What do you think?
/mjt
