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@xxxxxxxxxx> -- Andrea Bolognani / Red Hat / Virtualization
