Re: [PATCH RFC 0/6] spec: Decompose the daemon subpackage

On 11/24/22 03:57, Daniel P. Berrangé wrote: > On Wed, Nov 23, 2022 at 04:11:49PM -0700, Jim Fehlig wrote: > > Currently it is not possible to install a modular daemon subpackage without > > also installing the monolithic daemon > > > > https://listman.redhat.com/archives/libvir-list/2022-September/234554.html > > > > This series is an initial attempt at moving common daemons, utilities, and > > files from the daemon subpackage to a new daemon-core subpackage. The > > monolithic and modular daemons can then depend on the new subpackage. > > > > libvirt-guests is moved to a new libvirt-guests subpackage, which is > > recommended by the daemon subpackage to provide smoother upgrade. > > > > I've likely overlooked several items, but before continuing down this > > path too far I first wanted to gauge interest and see if this work is > > worth pursuing. If so, any comments on the RFC are appreciated! > > With this refactoring the two big questions > > - What is the desired end state > - Can we ensure a clean upgrade path > > Let me ignore everything except the QEMU driver and the nodedev driver, > for sake of illustration. > > Today we've got a few install approaches recommended > > - Ask for 'libvirt', which gives you > > - libvirt-daemon > - libvirt-daemon-driver-qemu > - libvirt-daemon-driver-nodedev > > All the libvirt pieces, but not the hypervisor itself > > > - Ask for 'libvirt-daemon-kvm', which also gives you > - libvirt-daemon > - libvirt-daemon-driver-qemu > - libvirt-daemon-driver-nodedev > - qemu-kvm > > All the recommended libvirt pieces for QEMU, including > the hypervisor itself > > > - Ask for 'libvirt-daemon-driver-qemu', 'libvirt-daemon-driver-nodedev', > which also gives you > > - libvirt-daemon > > The bare minimum libvirt pieces, but not the hypervisor itself Why not the hypervisor in this scenario?

> So I'd say we need to have > > - libvirt-daemon-lock > /usr/sbin/virtlockd > > - libvirt-daemon-log > /usr/sbin/virtlogd > > - libvirt-daemon-proxy > /usr/sbin/virtproxyd > I considered splitting these as you suggest, but wasn't sure if the proliferation of subpackages would receive a warm welcome :-).

> The libvirt-daemon-driver-XXX packages would then have *no* dependency > on anything. If you are asking for libvirt-daemon-driver-XXXX packages > of any kind, you're responsible for pickin the exact set of pieces you > want to have present. > > Installing 'libvirt-daemon' will give you libvirtd, virtproxyd, virtlockd > etc, and you can ask for libvirt-daemon-driver-XXX on top. > > The 'libvirt-daemon-kvm' would give you the sensible set of pieces, > *not* included libvirt-daemon any more though on distro versions which > have switched to module daemons. > > The only thing we can't achieve this way is to install libvirtd and > QEMU, without having the module daemons present. I'm not sure that > matters though, if we aim to discontinue shipping libvirtd long term. Could be avoided by moving the qemu dependency to libvirt-daemon-driver-qemu right?