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

[Lennart Poettering]

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:
> > 
> > > 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.

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