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?
That was one of the reasons, but the other was that these are just written as QEMU specific tools, and I wanted to separate them from the general purpose tools.
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?
In libvirt-client-qemu and (a new) libvirt-client-python respectively With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|