[libvirt PATCH] spec: libvirt-daemon: Add optional dependency on *-client

[Andrea Bolognani]

On Mon, Nov 07, 2022 at 10:18:14AM +0100, Martin Kletzander wrote:
> On Fri, Nov 04, 2022 at 10:09:31AM -0600, Jim Fehlig wrote:
> > On 11/4/22 09:22, Martin Kletzander wrote:
> > > On Thu, Nov 03, 2022 at 05:24:18PM +0100, Jiri Denemark wrote:
> > > > The libvirt-daemon subpackage contains libvirt-guests.sh script (used by
> > > > libvirt-guests service), which requires virsh to actually work. But
> > > > since dynamic libraries were separated from libvirt-client to
> > > > libvirt-libs more than 6 years ago, libvirt-daemon no longer requires
> > > > virsh to be installed. So unless libvirt-client is explicitly installed
> > > > (either manually or by installing the libvirt meta package),
> > > > libvirt-guests will not work.
> > > >
> > > > Just adding libvirt-client as a dependency of libvirt-daemon would go
> > > > against the original idea behind splitting libvirt-client: users may not
> > > > want to install or use any client binaries on the host where the daemon
> > > > runs (either they just use various language bindings or access the
> > > > daemon remotely). To solve this we could possibly turn libvirt-daemon
> > > > into an empty package and separate the daemons and libvirt-guests into
> > > > subpackages to make sure we support both use cases, but marking
> > > > libvirt-client as Recommended for libvirt-daemon does the same job in a
> > > > much simpler way.
> > >
> > > Or you could just move the libvirt-guests files to libvirt-client
> > > package since they couldn't work without it anyway.
> >
> > This actually seems like a better approach, especially in the context of modular
> > daemons.
>
> Unfortunately, now that I think about it, that would have to be dealt with a
> little bit more so that people don't see the libvirt-guests being removed.
> Using "Provides" would not help, but in the combination with the Recommends it
> could, theoretically work.  I'll let Jiri think about it because he had a bunch
> of ideas and reasoning behind this decision.

libvirt-guests is a service, so it doesn't feel like it would fit
well in the libvirt-client package.

I think the Recommends is the right way to go, and to be honest even
a hard Depends wouldn't feel unreasonable: the main reason to split
the client bits from the server bits is so that *clients* can be very
lightweight, but the server is going to be heavyweight by definition
and going out of our way to avoid the extra ~1MB feels unnecessary.
virsh is *the* tool to manage, inspect and debug a virtualization
server, so why wouldn't you want to have it handy anyway?

Either as-is or with the Recommends upgraded to a Depends

  Reviewed-by: Andrea Bolognani <abologna at redhat.com>

-- 
Andrea Bolognani / Red Hat / Virtualization