[systemd-devel] /usr vs /etc for default distro units enablement

[Uoti Urpala]

On Fri, 2014-12-05 at 02:39 +0100, Lennart Poettering wrote:
> On Tue, 02.12.14 20:02, Uoti Urpala (uoti.urpala at pp1.inet.fi) wrote:
> > On Tue, 2014-12-02 at 01:51 +0100, Lennart Poettering wrote:
> > > On Tue, 18.11.14 16:09, Michael Biebl (mbiebl at gmail.com) 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.