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

[Uoti Urpala]

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:
> 
> > 2014-11-18 15:59 GMT+01:00 Colin Guthrie <gmane at 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.