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