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

On Tue, Jun 27, 2023 at 09:21:55AM -0700, Andrea Bolognani wrote: > On Mon, Jun 26, 2023 at 04:16:33PM -0600, Jim Fehlig wrote: >> On 6/26/23 10:06, Andrea Bolognani wrote: >>> 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. >> >> The openSUSE scriptlets use the 'service_add_pre' macro from the >> systemd-rpm-macros package >> >> https://build.opensuse.org/package/view_file/Base:System/systemd-rpm-macr... >> >> In the end, something like 'systemctl --no-reload preset $unit' is called. > > There might be some additional nuance that we're missing. I will try > to play around with openSUSE and understand the situation better > tomorrow. Yup, that was exactly it! I'll omit a bunch of details for readability and because I have to get off the computer shortly :) but you should still get the gist. In Fedora (and I guess upstream systemd) the %systemd_post RPM macro is defined as if [ $1 -eq 1 ]; then \ systemd-update-helper install-system-units %{?*}; \ fi where the install-systemd-units command is implemented as systemctl --no-reload preset "$@" So whenever a new package is installed, the preset is going to be applied to all the units passed to the macro; subsequent runs of the scriptlet, during upgrade, will leave things alone. In openSUSE (I'm talking about Tumbleweed specifically, but Leap implements the same idea, just in a slightly different way) things work differently: the %service_add_pre and %service_add_post macros call systemd-update-helper mark-install-system-units %{?*} and systemd-update-helper install-system-units %{?*} respectively, and those two helper commands are implemented as for unit in "$@" ; do if [ ! -e /usr/lib/systemd/system/"$unit" ]; then touch /run/systemd/rpm/needs-preset/"$unit" fi done and for unit in "$@" ; do if [ -e /run/systemd/rpm/needs-preset/"$unit" ]; then rm /run/systemd/rpm/needs-preset/"$unit" systemctl --no-reload preset "$unit" fi done

So at this point it should be obvious why you were unable to reproduce the issue on openSUSE: while in Fedora the decision about whether to apply the presets to a unit is based entirely upon whether the package that ships it is being installed from scratch or is an update, openSUSE looks at whether the unit existed on the machine before the package was installed and only applies presets for units that are newly introduced. Well, that, and having all units disabled by default in the presets, of course :) It seems to me that the openSUSE approach is far superior to the Fedora / upstream one, because as we've seen it deals gracefully with units being moved between packages. And that's not the only scenario: if we were to introduce a new unit to any existing package, for example, Fedora would not enable it by default regardless of presets.

In the immediate future, I think we should look into implementing a similar logic to that of openSUSE in the libvirt spec. This would take care of solving both of the issue that I have reported and the one that Martin has.

In the longer run, I think it would make a lot of sense to advocate for this approach to be adopted in Fedora and systemd upstream, which would both reduce our maintenance burden and ensure as many other projects as possible can benefit from it.