On Tue, 02.12.14 20:02, Uoti Urpala ([email protected]) wrote: > On Tue, 2014-12-02 at 01:51 +0100, Lennart Poettering wrote: > > On Tue, 18.11.14 16:09, Michael Biebl ([email protected]) wrote: > > > > > 2014-11-18 15:59 GMT+01:00 Colin Guthrie <[email protected]>: > > > > 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.
Well, things are not that easy. If distro Foobarix decides one day that from this day on sendmail should be enabled again by default, what is the "right" upgrade path for old installs? Should it be enabled now, because that's the new default for new installs? Or should it stay disabled, since that's what the user is accustomed to? I am pretty sure the latter. I mean, of course, you can play games and try to guess if sendmail was off when the upgrade took place simply because that used to be the default, or because the user/admin really didn't want it to run, which just accidentally happened to be the default. You have a 50/50 chance to win this guess, which makes the excercise quite moot I'd say. I'd really be conservative here: optional things that change their default should be left as is on updates. Of course, if something starts to be a necessity that wasn't one strictly necessary then one should do something about this, but usually in that case this would be a move from "systemctl enable" units towards statically enabled ones anyway. But again: if something was optional before, and is optional after, then be conservative, don't change things... > > 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. Sure, if you know that changes in your unit files actively break a previous default, then you should do something about it, but I think cases like this are best handled with careful, manually written postinst scripts, that do the right thing in the most defensive possible way. But blindly enabling all kinds of stuff just because the upstream default changed is really not a good idea I think. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
