On Tue, 2014-12-02 at 01:51 +0100, Lennart Poettering wrote: > On Tue, 18.11.14 16:09, Michael Biebl (mbi...@gmail.com) wrote: > > > 2014-11-18 15:59 GMT+01:00 Colin Guthrie <gm...@colin.guthr.ie>: > > > For the avoidance of doubt, I believe that running systemctl preset > > > should only ever happen on *first* install, never on upgrade or such like. > > > > > > > And what are you going to do, if the unit file changes? > > Say v1 had > > > > [Install] > > WantedBy=multi-user.target > > > > and version B has > > [Install] > > WantedBy=foo.target > > Package installs should probably not try to do something about this > case, just leave things as is.
I think this would be a very bad idea. Installing a system and then upgrading it should give you the same state as installing a newer system directly; silently leaving outdated configuration in use almost ensures that systems will fail/degrade over time. > I mean, let's not forget that admins should be able to define their > own targets and then enabled units in them and disable them > elsewhere. Package upgrades should not manipulate that. The first > installation of a package should enable a unit if that's what the > preset policy says, but from that point on the configuration is admin > configuration and not be changed anymore automatically. It's theoretically possible that the admin could have moved it to a different target, but that's the exception. The system should still sanely handle the normal case where the admin has changed nothing, and in that case leaving the unit in its original target is completely wrong. For example, if you move a unit from sysinit.target to multi-user.target and remove "DefaultDependencies=no" from the .service file, then leaving the installed symlink for sysinit.target will cause a dependency loop. Even in cases where the resulting configuration is not so obviously broken, differences from the behavior of new installs are always harmful. If the admin HAS changed the configuration, then silently ignoring package changes is still not good behavior: it's likely that the admin should at least check whether the local changes are still required/valid and fix the setup to match the new package behavior if needed. So overall, I think the rules for package upgrades should be: In the default no-local-changes case, package upgrades MUST change symlinks to match what a new package install would set. If local configuration changes can be detected, then the admin should be alerted to the need to check the configuration if possible. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
