On Tue, Dec 13, 2022 at 09:57:31AM +0000, Daniel P. Berrangé wrote:
On Sun, Dec 11, 2022 at 10:22:00AM -0800, Andrea Bolognani wrote:
Both packages should depend on libvirt-daemon-lock too, instead of just the libraries.
Nope, they shouldn't - that's the virtlockd server, which is completely separate from these plugins.
Okay, thanks for explaining this. I was clearly providing bad advice based on my flawed understanding of the situation O:-)
+%package daemon-plugin-lockd +Plugin for virtlockd +Requires: libvirt-libs = %{version}-%{release}
Maybe libvirt-daemon-lock-plugin-lockd? A bit verbose, but would help better differenciate it from other loadable drivers.
The other loadable drivers are in libvirt-dameon-driver-XXX packages, so IMHO it is already easily distinguished by being in a libvirt-daemon-plugin-XXX package. So lets keep it more concise as Jim has it named here.
I think the distinction is not as obvious to someone who's not intimately familiar with the inner workings of libvirt. And the files in question are stored in a directory called "lock-driver", not "lock-plugin", so I'd say we're not entirely consistent about it internally either :) There's another naming question that I've been thinking about: the libvirt-daemon-driver-foo convention made perfect sense when the (monolithic) daemon would load the various drivers, but as we progress further towards a fully modular future it starts to become awkward. For example, you will have a system where libvirt-daemon-driver-qemu is installed but libvirt-daemon is not. That feels weird. I don't have a great solution for this. My instinct would be to have a libvirt-daemon-foo for each foo:// that libvirt supports, and then probably libvirt-daemon-foo-bar or libvirt-daemon-foo-plugin-bar for each bar backend/implementation of foo://. But for the various hypervisor drivers, those names are already taken... Any ideas? -- Andrea Bolognani / Red Hat / Virtualization