macros.systemd: presets might be applied during package updates too

[fbuihuu]

Currently we only apply presets during package installations which makes sense in most cases.

However an installed package with no units might be starting shipping units through an update and in this case we also need to apply the presets.

[keszybz]

Indeed. Various hacks can be used to solve this, but nothing simple or pretty. Fortunately this doesn't come up that often, because new units that could be preset usually are new functionality and the default preset of 'disabled' is good for them.

One solution is to split out such new service into a subpackage, and add Requires both ways (to and from the main package). Then it is possible to use normal macros.

[fbuihuu]

Indeed. Various hacks can be used to solve this, but nothing simple or pretty

Yeah... I was hoping that you knew a fancy rpm feature that could solve this simply.

One solution is to split out such new service into a subpackage, and add Requires both ways (to and from the main package). Then it is possible to use normal macros.

Not sure packagers would like to create subpackages just for that purpose though

[fbuihuu]

BTW, SUSE is checking for the present of the units in %pre and create a marker (tag file) if it's not there. %post checks for the present of the tag file and apply the preset if it's there.

Not pretty but at least the corner case is covered.

[yuwata]

If I understand it correctly, I think it is enough to write systemctl preset foo.service in rpm trigger script. Right? So, I do not agree that the macro always call systemctl preset. I am worried about that it may brake many already existing environments.

[fbuihuu]

If I understand it correctly, I think it is enough to write systemctl preset foo.service in rpm trigger script. Right?

Sorry I don't understand what you meant here. Care to explain ?

Thanks.

[keszybz]

OK, so what about adding a new macro that takes the package version as an argument, and does the preset when upgrading from a version that was older than this version:

%systemd_post_new_service 15.0.0 service1.service

The first argument would be a version of the package that added the new service, and the second would be the name of the service itself. It would expand into a trigger that would run when a version of the package older than the specified argument would be uninstalled:

%triggerpostun -- %{name} < %1
systemctl --no-reload preset %{?2} %{?3} %{?4} %{?5} %{?6} %{?7} %{?8} %{?9 } &>/dev/null || :

Details to be figured out ;)

[keszybz]

By the way, http://ftp.rpm.org/api/4.4.2.2/triggers.html is the "best" documentation I could find. It seems that newer rpm versions lost the scant documentation they had for this.

[yuwata]

@fbuihuu Sorry, I missed your request.

If I understand it correctly, I think it is enough to write systemctl preset foo.service in rpm trigger script. Right?

Sorry I don't understand what you meant here. Care to explain ?

If packages always enable services, then users need to disable unwanted services after every update. E.g., fedora ships preset which enables NetworkManager.service. If a user want to use systemd-networkd instead of NetworkManager, but because of rpm dependency it may not possible to uninstall NetworkManager. In such a case, NetworkManager is always enabled when the package is updated.

So, I think %trigger scripts are favorable instead of %post script, and I like the proposed method by @keszybz.

[fbuihuu]

@yuwata thanks but I don't think the initial plan was to apply preset unconditionally during package updates.

[yuwata]

Yeah, my original comment is for the initial proposal by @keszybz:

One solution is to split out such new service into a subpackage, and add Requires both ways (to and from the main package). Then it is possible to use normal macros.

[fbuihuu]

Thanks @keszybz for your idea and pointer.

I'm not sure if relying on a package version is a good idea and is easily maintainable even if it has the advantage to not use a state file (to record if a package has been already "preset'ed") like it's done with the SUSE approach.

Actually I just remember issue #4830 which should solve this issue properly: the actions performed by sysadmins (enable, disable) should be recorded in /etc whereas the presets applied by packages should operate in /usr only.

That way we could apply presets unconditionally during package installations/updates without interfering with sysadmin preferences.

[yuwata]

Hmm. I have not followed the discussion in #4830. But is it possible to migrate the system from which does not have such admin-action records?

[fbuihuu]

The problem is that currently there're no ways to figure out if a service has been explicitly enabled/disabled by the sysadmin or if it's been enabled during package installation (according to the presets).

During such migration we could run a tool which would remove all symlinks in /etc that matches the preset states assuming that they were created during package installations and that the sysadmin is fine to follow the distro defaults (even if they might be changed in the future).

But regarding this specific issue which is about the introduction of new services during package updates, they won't be any problem I think.