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

On Thu, Aug 31, 2023 at 01:43:44AM -0700, Andrea Bolognani wrote: > 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? I don't much like it to be honest, as I was hoping we would get away from having it exist in any new installs, such that people were not mis-directed into trying to use it.

I'm not seeing a good way to deal with the upgrade problem though. I could possibly make the argument that Fedora has defaulted to modular daemons for new installs for long enough that we should assume all installs are running modular. Still, we have a proof by counter-example that such an assumption is not entirely true. I guess your proposal here is still better than the historical practice though, because even if it gets installd by default, we can at least now erase it if desired. Possibly the next step would be to stop building libvirtd by default in upstream releases[1], and figure out a way to attempt to auto switch installs to modular daemons during upgrade. And then eventually we can delete it entirely upstream.