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