capstone is still in universe and ends up directly in the binaries of qemu-system*, qemu-user* - so we can't enable that.
Since no one asked for it providing a case worth the effort, I'm not triggering an MIR for it.
vde2/libvdeplug-dev is in universe, but despite being a storage backend it does not end in the build as a module - instead [1] shows that its dependencies end up directly in the qemu-system-* binaries - so we can't enable that without an MIR.
Since no one asked for it providing a case worth the effort, I'm not triggering an MIR for it.
capstone is still in universe and ends up directly in the binaries of qemu-system*, qemu-user* - so we can't enable that.
Since no one asked for it providing a case worth the effort, I'm not triggering an MIR for it.
vde2/libvdeplug-dev is in universe, but despite being a storage backend it does not end in the build as a module - instead [1] shows that its dependencies end up directly in the qemu-system-* binaries - so we can't enable that without an MIR.
Since no one asked for it providing a case worth the effort, I'm not triggering an MIR for it.
[1]: https:/ /buildd. debian. org/status/ fetch.php? pkg=qemu& arch=amd64& ver=1%3A7. 2%2Bdfsg- 1%2Bb2& stamp=167212856 4&raw=0
libnfs is in main since focal and ends up in qemu-block-extra, ok to enable even without splitting the package.
So overall one of the three checked can be enabled, and that doesn't even need a complex package split.