On Mon, Nov 28, 2022 at 10:53:52AM -0700, Jim Fehlig wrote: > 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? 'qemu-kvm' is a "typical installation" of QEMU packages on Fedora. People wanting minimal installations want to fine tune exactly which qemu-kvm-XXXX sub packages they install. So we don't force any dep from 'libvirt-daemon-driver-qemu', let the user choose exactly what they want. > > 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 :-). We lost the non-proliferation war years ago ;-P Three more is merely noise > > 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? See above for why we don't have a qemu dep from there. 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 :|
