Re: [libvirt PATCH] rpm: Recommend libvirt-daemon for with_modular_daemons distros

On Wed, Aug 30, 2023 at 07:25:23PM +0200, Erik Skultety wrote: > On Wed, Aug 30, 2023 at 06:22:33PM +0200, Andrea Bolognani wrote: > > A default deployment on modern distros uses modular daemons but > > switching back to the monolithic daemon, while not recommended, > > is still considered a perfectly valid option. > > > > For a monolithic daemon deployment, the upgrade to libvirt 9.2.0 > > or newer works as expected; a subsequent call to dnf autoremove, > > however, results in the libvirt-daemon package being removed and > > the deployment no longer working. > > > > In order to avoid that situation, mark the libvirt-daemon as > > recommended. > > > > This will unfortunately result in it being included in most > > installations despite not being necessary, but considering that > > the alternative is breaking existing setups on upgrade it feels > > like a reasonable tradeoff. > > > > Moreover, since the dependency on libvirt-daemon is just a weak > > one, it's still possible for people looking to minimize the > > footprint of their installation to manually remove the package > > after installation, mitigating the drawbacks of this approach. > > Not just that, experienced users can even skip installation of it with using > '--setopt=install_weak_deps=False'. Yeah, but that tells dnf to skip *all* weak dependencies, so for example you won't get passt either, which you might have wanted. apt is better in this regard, because while you can use $ apt-get install --no-install-recommends libvirt-daemon-kvm to skip all weak dependencies, same as dnf, you can also use $ apt-get install libvirt-daemon-kvm libvirt-daemon- (note the trailing -) to install all other weak dependencies but skip libvirt-daemon specifically. > Footprint aside, I don't see a practical > problem having both installed even if unused since it allows users switching > between the deployment modes seamlessly without having to go and install an > extra package. Having both available means that it's easier for people to end up with messed up deployments. For example, some automation that was written before modular daemons were introduced might unconditionally enable libvirtd. If libvirtd is present on the machine, that will result in both modular and monolithic daemons being enabled; if it isn't, you will get an error message and an opportunity to improve the automation so that it's aware of modular daemons. That said, this has been the status quo for the last few years, when it was simply not possible to get rid of libvirtd, so this patch at least doesn't make things any worse :) > FWIW: > Reviewed-by: Erik Skultety <eskultet(a)redhat.com&gt; Thanks. Daniel, Jirka, do you have any objections or can I go ahead and merge?