On Fri, 2014-12-05 at 02:39 +0100, Lennart Poettering wrote: > 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: > > > > 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?
The context here was a package changing its install target, not changing default enable/disable behavior as in your example. The latter is a less clear-cut case: if the unit has a [Install] section, then presumably the packager considers both enabled and disabled state supported at least to some degree, and thus both are explicitly valid choices even on newly installed systems. By contrast, leaving symlinks from targets that do not match the [Install] section of the current service file anymore is more arbitrary reconfiguration, which cannot be expected to work in general (as in linking arbitrary units from arbitrary targets is not expected to work), and it's the admin's responsibility to investigate what he needs to do to make such configurations work and keep them working. Keeping such obsolete configuration would mean that systems rot over time. Package configuration files are not handled that way, and package startup configuration shouldn't be either, for the same reasons. Just leaving the symlinks would not give good behavior even in the case where the admin wants to keep the old target: temporary disable + then re-enable would now change the target. Perhaps the recommended way to change targets in local configuration should be to override the [Install] section, instead of just leaving different symlinks? > units towards statically enabled ones anyway. But again: if something > was optional before, and is optional after, then be conservative, > don't change things... IMO in the changing-targets case it's not "conservative" at all to silently leave the system in a state where it has obsolete configuration which does not match anything supported by the current packaging. Such behavior is almost 100% guaranteed to break things at some point. "Conservative" would be something like refusing to upgrade until the admin resolves possible conflicts manually. If no local configuration can be detected, using the new packaging defaults has a better chance of avoiding breakage than leaving obsolete configuration. > 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. The new defaults could enable more things, or they could disable parts that are now deemed insecure or unnecessary, or just generally fix bugs. The sane default assumption is that later package versions are better than earlier ones, and leaving the system using old default configuration is worse than new configuration. And that's assuming the old configuration even works anymore given changes elsewhere. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
