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.