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

[Jim Fehlig]

On 6/30/23 10:58, Andrea Bolognani wrote:
> 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-macros/macros.systemd?expand=1
>>>
>>> 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

I followed the paper trail here and copied that 'systemctl' command in a 
previous response, but shame on my laziness and not looking at the pre macro to 
see the bigger picture. Once again, thanks for the snooping.

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

Yep, understood. The openSUSE approach is more flexible and avoids per-package 
hacks to handle such scenarios.

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

Agreed. Were you planning to work on that? If you don't have time in the near 
future, I should have some cycles next week after the US holiday.

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

Agree with this too, but not volunteering to work on it :-).

Regards,
Jim