[libvirt PATCH v3] tools: add virt-qemu-qmp-proxy for proxying QMP via libvirt QEMU guests

[Andrea Bolognani]

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