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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux