Michael Tokarev wrote on Thu, Feb 12, 2026 at 03:38:54PM +0300: > > 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.
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. > > 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. 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 :) > 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. 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...) > 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. 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, -- Dominique
