https://bugzilla.suse.com/show_bug.cgi?id=1177039 https://bugzilla.suse.com/show_bug.cgi?id=1177039#c5 Franck Bui <fbui@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fbui@suse.com --- Comment #5 from Franck Bui <fbui@suse.com> --- 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. -- You are receiving this mail because: You are on the CC list for the bug.