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@redhat.com> -- Andrea Bolognani / Red Hat / Virtualization