Re: [libvirt PATCH v3] tools: add virt-qemu-qmp-proxy for proxying QMP via libvirt QEMU guests
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