On Sat, 23 May 2026 at 19:18:19 +0300, Michael Tokarev wrote:
That's already the case. qemu-system-common is only built if any
of qemu-system-$arch is built. But I don't think it will help much.
Because while 32bit systems was a major difference, there's no other
similar changes expected. So far we assume qemu-system is available
on all 64bit architectures.
I thought qemu needs explicit porting for every new architecture? Or is
that only necessary for KVM and new emulated architectures, with every
new 64-bit architecture (let's say wtf64) immediately being able to
emulate existing architectures (for example qemu-system-x86:wtf64)
without writing new code?
At the moment, qemu seems to hard-code an allowlist of architectures:
Package: qemu-system-common
Architecture: amd64 arm64 loong64 mips64 mips64el ppc64 ppc64el riscv64
s390x sparc64
so next time we gain a new 64-bit architecture (let's say wtf64), no new
qemu-system* packages will be built for it until the qemu maintainers
add wtf64 to that list and similar ones. I don't think we want
gnome-boxes:wtf64 to get built but not be installable: that would be a
RC bug.
If your intention is that qemu will be built on every 64-bit
architecture, then you could consider using
Source: qemu
Build-Depends: ..., architecture-is-64-bit, ...
Package: qemu-system-x86 # etc.
Architecture: any # or maybe linux-any
although that would only work after removing the 32-bit builds of
qemu-utils.
BTW, (*-)Depends: qemu-system-common is a tough one. The prob here
is that qemu-system-common itself depends on one of qemu-system-foo
packages, - due to old request from ubuntu. I think I now got rid
of this dependency, but it was there for quite some time.
For the version currently in unstable, which is the only one that
matters for new unstable packages, that dependency is no longer there.
After uploading a version of gnome-boxes that doesn't build on armhf
and i386, we'll need to ask the archive team to remove the old
gnome- boxes:i386 and gnome-boxes:armhf binaries, and a similar
request will be necessary to remove qemu*:i386 and qemu*:armhf
packages that are no longer built, and probably similar for libvirt
and libvirt-dbus. And then, after all that cleanup, qemu will
finally be able to migrate.
I guess it's just tip of an iceberg. There are much more packages
involved. I'm filing more bugs like this one, for inter-inter-deps..
Looking at https://qa.debian.org/excuses.php?package=libvirt and
https://qa.debian.org/excuses.php?package=qemu I think it's only:
- qemu itself
- qemubuilder
- libvirt
- libvirt-dbus
- gnome-boxes
cockpit-machines depends on libvirt-dbus, but is Architecture: all, and
the testing machinery allows Arch: all packages to become uninstallable
on architectures that are not amd64 or arm64, so that's OK.
`dak rm -R -n -b gnome-boxes gnome-devel libvirt-dbus cockpit-machines
qemubuilder` on coccia doesn't complain about any other rdeps.
smcv
