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


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.

-- 
Andrea Bolognani / Red Hat / Virtualization




[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