DevHeads.net

dropping %systemd_requires from most packages (guidelines change and mass package update proposal)

Hi,

let's drop the requirement and ordering on systemd (as implemented by
%systemd_requires) from packages which provide systemd units.

I now filed [1], which removes the recommendation to use %systemd_requires.
Quoting from that ticket:

Nowadays systemd.rpm does a preset-all call when it is installed.
This means that individual packages which provide systemd units and
call %systemd_post in their %post will work fine no matter if they
are installed *before* or *after* systemd.

If installed *after*, the sequence is:
...
1. install systemd, systemctl preset-all is called
2. install package with a.service, %systemd_post calls systemctl preset a.service
(a.service is enabled if presets say so).

If installed *before*:
...
1. package is installed, %systemd_post calls systemctl preset a.service, but
nothing happens because /usr/bin/systemctl is not found.
(The scriptlet is conditionalized using [ -x /usr/bin/systemctl ], so no
error or warning is emitted.)
2. systemd is installed, systemctl preset-all is called
(a.service is enabled if presets say so).

If systemd is not installed at all:
the service is never enabled, and there's generally no way to run the service
using systemd. This might happen for example when building a custom container
image or systemd portable. I think that's totally reasonable, if systemd should
be used in the image, it should be declared explicitly, and not pulled in as
a dependency of some random package.

During upgrades:
%systemd_postun_with_restart calls systemctl try-restart. If systemd is not
installed, than the service is obviously not running, so there's nothing to
restart.

The advantages of removing the dependency are:
1. it is easier to build custom images of various sorts, because systemd is
a big package and pulls in a *lot* of dependencies. For specialized use cases
this is totally unnecessary.
2. when those depencencies are removed, rpm has more freedom to order
the transaction. In case there are other constrains on the ordering
(that actually matter), there's less chance of circular dependencies and
it's more likely that rpm will be able to honour those other constraints.
3. "less is more" in general.

Please note that this applies to calls to systemctl preset and
systemctl try-restart. If the package calls some other systemd tool,
for example systemd-tmpfiles or systemd-sysusers, or otherwise requires
systemd to be installed, it should retain appropriate dependencies.

If this change is accepted by FPC, I'll do a mass package change using
pp privs to remove %systemd_requires use in obvious cases, i.e. when the
scriptlets simply call %systemd_{post,postun,preun}. I think it'd be great
to get rid of those dependencies for F31.

[1] <a href="https://pagure.io/packaging-committee/pull-request/890" title="https://pagure.io/packaging-committee/pull-request/890">https://pagure.io/packaging-committee/pull-request/890</a>

Zbyszek

Comments

Re: dropping %systemd_requires from most packages (guidelines ch

By =?UTF-8?Q?M=c3=... at 05/09/2019 - 10:19

On 5/9/19 9:00 AM, Zbigniew Jędrzejewski-Szmek wrote:
Is this true for the version of systemd in RHEL 7 and compatible as well?
How will this affect EPEL packages?

Re: dropping %systemd_requires from most packages (guidelines ch

By Zbigniew =?utf-... at 05/09/2019 - 10:46

On Thu, May 09, 2019 at 09:19:32AM -0500, Mátyás Selmeci wrote:
systemd in RHEL generally follows the changes in Fedora, with a delay.
If this is changed in F31, then it wouldn't filter down to RHEL until
the next RHEL release. Similarly, such changes should not be propagated to
packages in EPEL7.

Zbyszek