Comment # 5 on bug 1177039 from Franck Bui

Nope I can't recall any similar case. The nearest one I can remember was about
a package that renamed a service unit file but that's different.

It seems to me that the root cause of this issue is the way rpm artificially
handles package renames. There's also a shortcoming in the way the preset stuff
generates the symlinks currently but I don't think it is the root cause.

In my understanding when rpm renames a packages it does that artificially by
removing the old package and installing the new one. In this sequence the info
about the ongoing package update is lost and therefore breaks any actions that
need to be done only once at package installation. So I don't think this
problem is tied to systemd.

Now, even it's not the root cause IMO, there's also an issue with the way the
presets are applied and where the symlinks are stored. Those enablement
symlinks are created in /etc/systemd/system/*.{requires,wants} during package
installation, ie at runtime.

The problem is that the symlinks are placed in /etc which is wrong because it
may interfere with sysadmins later customization. Therefore currently presets
should be applied only once at package installation. This is problematic as
this bug showed but there are other cases too. For example if we need later to
change the default enablement state for a given package and decide that package
"foo" needs to be disabled by default on systems (because of a security reason)
we're screwed.

The solution to this problem is that presets should create symlinks in /usr
instead and it should be done at package build time so the symlinks can be
shipped and owned by the package itself.

Now this would require some changes in systemd which are not trivial but it's
doable. The hardest parts to me are how we integrate the most transparently the
preset handling during package builds and how we deal with existing systems
since sysadmins may have enabled/disabled any installed services.