Please split the qemu-user-static package into multiple separate
packages, for each target on each architecture.  I am a frequent user
of qemu-user-static for cross-chroots, but I only care about a small
subset of architectures (specifically armel and powerpc on amd64 hosts
as well as armel and i386 on powerpc hosts).  I'd prefer not to have
to install and update a 30MB package to achieve these narrow goals.

Thank you.

I think this shall be wontfix. Apart from some ludicrous corner cases, this
package isn't ever installed on machines where space is a relevant issue.
The cross-chroots alone are many times bigger than the qemu package.
Furthermore, the extra work overhead of maintaining many tiny packages
(and introducing new one every time a new target is added) is just not
worth it.

Likewise for the system-emulator bug, where the qemu images go by gigabytes of
size.

Riku

when multi-arch is supported, this gets more interesting, as you could install
the appropriate host architecture binary in the chroot itself, and get updates
through apt.

by packaging into related collections that are known to work in a cross-chroot
(arm, mipsel, powerpc, as far as i know), and another package with all the
other variants, i think we can keep the packages to a reasonable number.


live well,
  vagrant

Hello,

now that qemu-system has been packaged in diferent files for each emulated
architecture, we may change Depends to Recommends and install only the
architectures that we need,

for example, if an user only wants that qemu emulates only x86 architecture,
he saves 104MB of disk space:

sed -i -re '\|^Dep(ends: qemu-system-arm, qemu-system-mips, qemu-system-
ppc)| s||Recomm\1|' /var/lib/dpkg/status

aptitude -y purge qemu-system-arm qemu-system-mips qemu-system-ppc qemu-slof
qemu-system-sparc qemu-system-misc # qemu-system-x86

The following packages will be REMOVED:
  qemu-slof{p} qemu-system-arm{p} qemu-system-mips{p} qemu-system-misc{p}
qemu-system-ppc{p}
  qemu-system-sparc{p}
0 packages upgraded, 0 newly installed, 6 to remove and 1 not upgraded.
Need to get 0 B of archives. After unpacking 104 MB will be freed.
(Reading database ... 77445 files and directories currently installed.)
Removing qemu-system-ppc ...
Removing qemu-slof ...
Removing qemu-system-arm ...
Removing qemu-system-mips ...
Removing qemu-system-misc ...
Removing qemu-system-sparc ...
Processing triggers for man-db ...

This could be even better if when reconfiguring the qemu-system package, a
multiselect list will be shown to the administrator and he chooses some of the
architectures or all of that,

Kind regards,

Jordi Pujol

Live never ending Tale
GNU/Linux Live forever!
http://livenet.selfip.com

14.06.2013 11:05, Jordi Pujol wrote:

I don't really understand why you want this.

If you don't want whole thing, just install the individual package you want,
there's no need or reason to ask.

Thanks,

/mjt

A Divendres, 14 de juny de 2013 09:21:24, Michael Tokarev va escriure:
I think that now is not possible to install only one architecture?

excerpt from the debian/control file in the source package, version qemu
1.5.0+dfsg-4:

Package: qemu
Architecture: amd64 arm armel armhf hppa i386 ia64 kfreebsd-amd64 kfreebsd-
i386 mips mipsel powerpc ppc64 s390x sparc sparc64
Multi-Arch: foreign
Depends: ${misc:Depends}, qemu-system (>= ${source:Version}), qemu-user (>=
${source:Version}) [linux-any], qemu-utils (>= ${source:Version})
Suggests: qemu-user-static [linux-any]
...
Package: qemu-system
Architecture: amd64 arm armel armhf hppa i386 ia64 kfreebsd-amd64 kfreebsd-
i386 mips mipsel powerpc ppc64 s390x sparc sparc64
Multi-Arch: foreign
Depends: ${misc:Depends},
 qemu-system-arm,
 qemu-system-mips,
 qemu-system-ppc,
 qemu-system-sparc,
 qemu-system-x86,
 qemu-system-misc
Description: QEMU full system emulation binaries

14.06.2013 11:34, Jordi Pujol wrote:
[]

First, please tell me how this is related to qemu-USER-static?

Qemu is a meta-package, it installs all of qemu.  Just like, for example, gnome
installs all of gnome.  Ditto for qemu-system which is also a meta-package
which installs all of qemu-system targets.

I can only repat myself.  If you don't need something, don't install it.
If you installed whole qemu, please don't complain that you don't want
some part of it, -- uninstall whole qemu and install just the parts you
need.  There's no need to ask questions, you choose what to install.

Please don't hijack bugreports with irrelevant questions.

Thanks,

/mjt

package, and the requirement is related to that, sorry if I have chained
this incorrectly,

Tagging as wontfix.  I really see a reason to split qemu-user packages into
parts.  Disk space is cheap, and there aren't any further dependencies, and
you get whole thing without much thinking which one do you need (which, with
many similar arches like -arm -armel etc, may become a real question).

Thanks,

/mjt

Hi mjt,

Sorry for mudding with such an old one... It was listed in reportbug :)

back in 2011 the package was apparently 30MB but it's now grown to close
to 500MB:
$ apt info qemu-user | grep Size
Installed-Size: 476 MB
Download-Size: 71.0 MB

(qemu-user-static was 380MB in bookworm, 280MB in bullseye, so it's been
steadily growing)

I kind of agree that it's not usually installed on size-constrained
environments, but the reason I looked into it was that we're shipping a
"development environment" VM image with it installed, and we'd
appreciate reducing the install footprint where possible.
(even if yes, it's too late for trixie, that'll be useful for future
releases)


Given qemu-system has been through the split already you probably
understand better than me how much effort would be involved in the
split: how much work would this be?
I won't pretend I'll do this quickly (will be summer at best) but if you
don't have time would you accept a PR on salsa to try to do something
similar?

I presume it'd need adjustment to the binfmt scripts as well to
determine what's been installed, so some legwork first...


Thanks,

Hi!  Thank you for an interesting bug report!

I see your point.  I didn't think about the size issue when I merged
qemu-user-static into qemu-user for trixie.  Indeed, this might be
a problem, though a somewhat minor one.
into one in a near future, I very much hope.  Not because we've grown
more space, but because upstream is working towards single-binary
qemu-system which implements all architectures in one.  That'd be a
great change.

Speaking of qemu-user split, - this isn't really difficult, it's a one-
evening work, and next waiting in the debian NEW queue for the package
to be reviewed and accepted.  Since everything's scripted in there, it's
easy to do.

I'm not yet sure wrt the split of qemu-user-binfmt though - it's an
interesting question.  If we split qemu-user, there will be no need
in qemu-user-binfmt, since for a split-out version, we can register
whatever architectures which are being installed.  But not if whole
qemu-user is installed without qemu-user-binfmt.. this is a quite
weird situation.

It's.. interesting, it really is.

Tho I'm sort of afraid to rearrange qemu-user once again, - it's been
quite seriously reorganized for trixie, bothering too many people in
the process.  The same happens with qemu-system too, especially before,
when we had no mechanism to depend on particular architecture, so
users depended on qemu-user-misc, etc - and it was sort of painful
to split.

Fun stuff.  I'll think about this more.

Once again: the problem here is not the actual packaging work, it is
easy to do and will be fast (modulo sitting in the NEW queue).
The problem which needs to be worked out is the logic with binfmt
registration.  Current situation is to avoid registration if only
qemu-user is installed.

The initial step might be to split qemu-user into multiple packages,
keep qemu-user as a meta-package, and provide qemu-user-binfmt just
the way it now is.  This way, at least nothing breaks compared to the
current setup.  But in case of split, I'd rather register each binfmt
in individual qemu-user-$arch packages at install, and drop
qemu-user-binfmt entirely.

Thanks,

/mjt

Michael Tokarev wrote on Thu, Feb 12, 2026 at 03:38:54PM +0300:

No worry. We actually already had qemu-user-static in our old images,
but the size increase has been noticeable enough to flag the package
(just looking at dpigs in debian-goodies) -- there's no hurry for me.

Interesting!
I'm curious about the tradeoffs (oh, looking at this semi-old talk[1] it
seems to be about heterogeneous systems more than size), but I'll leave
it up to upstream here.
[1] https://pretalx.com/kvm-forum-2025/talk/ZFLGZZ/

I guess depending on how it's done some split could still be done
(e.g. dynamic linking and only pulling in each arch's .so in
subpackages) but it's probably not worth the effort, and a first
approximation could be to just have qemu-system provide all the old
qemu-system-* so it'll be picked up on upgrades from system with a
subset of packages installed?
Sounds like more headaches for you, I wish you all the best.

I'll keep reading a bit more about the unification out of curiosity
though, thanks for the word about it :)

Yes, looking at how qemu-user-binfmt works now, you probably could have
the config (/usr/lib/binfmt.d/qemu-*.conf) moved in qemu-user-* just
like /usr/share/qemu/binfmt.d/qemu-*.conf is already there, and
qemu-user-binfmt should actually keep working just like it does?

(and I actually ought to remove the qemu-user-binfmt package on my
system since the work is done twice, but I understand the use of keeping
it for compatibility on upgrades -- and there's also systemd-less debian
variants like devuan that do need it, if you care about these...)

Sorry to read that :(
As you suggested below, I assume having a virtual package like
qemu-system that pulls in all the arches would mostly be transparent,
but please do think about this some more -- there's no hurry on my end.

Thank you,