On Mon, Nov 28, 2022 at 08:33:27AM -0800, Andrea Bolognani wrote:
On Wed, Oct 05, 2022 at 11:51:05AM +0100, Daniel P. Berrangé wrote:
Since this tool introduces a python dependency it is not desirable to include it in any of the existing RPMs in libvirt. This tool is also QEMU specific, so isn't appropriate to bundle with the generic tools. Thus a new RPM is introduced 'libvirt-clients-qemu', to contain additional QEMU specific tools, with extra external deps.
[...]
+%package client-qemu +Summary: Additional client side utilities for QEMU +Requires: %{name}-libs = %{version}-%{release} +Requires: python3-libvirt >= %{version}-%{release} + +%description client-qemu +The additional client binaries are used to interact +with some QEMU specific features of libvirt.
Jumping into this a bit late O:-) but I'm wondering if this was the right call, naming-wise?
It appears to me that the primary reason to want this (and now virt-qemu-sev-validate) to be in a separate package is really the dependency on Python, which we understandably don't want to become a requirement for the existing libvirt-client package. So wouldn't libvirt-client-python be a more accurate and future-proof name?
Suppose later we introduce a tool that's QEMU-specific but written in C, or a tool that's not specific to any hypervisor driver but written in Python. Where would those go?
Any thoughts on this? I'm going to introduce the new binary package in Debian soon, and while I would prefer to match upstream's names as much as possible I'm still not fully convinced by the choice made here. -- Andrea Bolognani / Red Hat / Virtualization