Hi! Thank you for an interesting bug report!
On 2/9/26 05:07, Dominique MARTINET wrote:
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)
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.
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?
It's fun you mentioned qemu-system - this set of packages will be merged
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
