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 :|
