Re: [PATCH] spec: Do not disable some systemd units of newly split package

On Fri, Jun 16, 2023 at 03:57:37PM -0600, Jim Fehlig wrote: The current logic in all packages' %post scriptlet basically translates to: if installing the package from scratch, apply the systemd presets; if upgrading, leave things well alone. What I would want the witness file to indicate would be: libvirt-daemon is being upgraded, so when running the %post for libvirt-daemon-proxy behave as in the upgrade scenario as opposed to the install-from-scratch scenario. Detecting whether the monolithic libvirtd and its sockets are enabled could also work, but feels more fragile. Specifically, it would not cover the scenario described by Martin, where the deployment is a split daemon one but with some units that are disabled by default based on presets have been manually enabled by the admin. The problem is that I'm not sure we can create and process such a witness file reliably. Figuring that out requires research and real-life testing :) I'm not sure this is entirely relevant, but just for completeness' sake: in a monolithic daemon deployment, you want libvirtd.service in addition to its sockets to be enabled. This is needed to make sure domain autostart works as intended. Basically, starting from a split daemon deployment, you want to follow the steps outlined here[1] but in reverse. I'll try to reproduce this myself later this week, but what you're describing doesn't match my expectations: virtproxyd.socket should have been enabled during installation. Are the packages you're using for testing a direct rebuild of the spec file shipped upstream? Or have you integrated the changes into the openSUSE spec file somehow? Note that the scriptlets in the upstream spec file call out to some standard macros, and it's also possible that the implementation of said macros is not the same across Fedora and openSUSE. They're part of the fedora-release package[2]. Specifically, we have # Virtualization driver specific daemons. Start by default at boot for VM # autostart, but shutdown after 2 mins and socket activated thereafter enable virtqemud.service enable virtxend.service enable virtlxcd.service # Compatibility with libvirtd sockets for old clients and expose TCP sockets enable virtproxyd.socket # Secondary drivers providing supporting functionality to main virtualization # drivers, socket activated only when required enable virtinterfaced.socket enable virtnetworkd.socket enable virtnodedevd.socket enable virtnwfilterd.socket enable virtsecretd.socket enable virtstoraged.socket Are you okay with old(ish) clients not being able to connect to the host? Because that's why the virtproxyd.socket is enabled by default in Fedora: if the client predates the introduction of split daemons it will try to connect to the old libvirtd socket, and in a split daemons deployment they only way to make that work is by having virtproxyd listening on it. [1] https://libvirt.org/daemons.html#switching-to-modular-daemons [2] https://src.fedoraproject.org/rpms/fedora-release/blob/rawhide/f/90-defau... -- Andrea Bolognani / Red Hat / Virtualization