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?