On 10/14/22 23:34, Jim Fehlig wrote: > > Yes, it does. Thanks for the detailed response! I suppose we'll need to > rethink the dependencies in our downstream packages. E.g. currently it's > possible to install qemu-ui-spice-core (which contains > ui-spice-core.so), but not qemu-chardev-spice (which contains > chardev-spice.so). That seems to fly in the face of the upstream logic. Ah, so this kind of warrants resurrection of the old capability, because the assumption the commit which retired the capabilty made is not correct anymore (thanks to qemu dynamically loading modules). BUT, if we want to do so, we must remove the X_ prefix first because that prefix is reserved for retired capabilities [1]. But yeah, breaking down qemu too much, into many separate packages looks like overkill. And I see you already posted v3 so let me review that. Michal 1: Why we don't just remove the capability from virQEMUCaps enum? Because in the domain status XML we store the set of qemu capabilities the domain was started with. And then, when libvirtd restarts we use that str2enum helper (declared at the beginning of qemu_capabilities.c) to reconstruct the capabilities bitmap. QEMU and Libvirt might have been upgraded after the domain was started. And if we were to remove a capability, the str2enum helper would simply fail and we wouldn't be able to reconstruct the caps.
