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
