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