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

[Tom Gundersen]

On Tue, Nov 18, 2014 at 4:21 PM, Didier Roche <didrocks at ubuntu.com> wrote:
> The thing I'm afraid of that we won't have a single place to list all
> disable units, and they will be in multiple packages, so (as I'll repeat
> below), I'm unsure that we would able to only load the preset as once shot,
> as we may add some preset files as part of packages later on with the
> current structure (to disable more units by default).

I'm not familiar with Debian packaging, but the way I would imagine
this working would be to call preset once all the packages in your
transaction have been installed. That way, no matter which package
ships the preset files, whatever  preset files are installed by the
time your current upgrade/install transaction completes are what will
determine if a certain unit should be enabled.

Of course, if you install first your package, and then in a separate
transaction install some preset files with overrides, these will not
be applied retroactively, but I would fond that behaviour very
surprising to be honest. Of course, it would still be possible to do a
retroactive preset thing with some amount of hacking, but I'm really
not convinced that it makes sense to explicitly support upstream.

>> This is up to the distro I guess, but I would have thought that
>> presets should only be applied on install-time, and not on upgrade.
>
> You mean system install time, right? Having it one shot would be more
> complex in our case I think as stated above (I guess, we'll have the disable
> distributed in multiple packages, not all being installed by default).

I meant package-install time (which may be different from
system-install). I.e., after every package transaction, do the presets
on all newly installed packages.

>>> agreed as well, or, this would be a way for the sysadmin to "stick" this
>>> unit/service whatever future distro will choose in the next upgrade.
>>
>> Could be, yeah, but moving from static to opt-in during an upgrade
>> sounds like a packaging bug to me, so hopefully this situation would
>> never be encountered in production.
>
> It should not happen in production, indeed, but packaging errors happen and
> we should maybe be able to recover without having impacts on admins who
> systemctl enable this unit in particular for their needs?

What I meant is that it sounds strange for admins to be proactively
enabling static units if the policy is that they should never be
automatically disabled on upgrade. We may still want to make this as
smooth as possible for those who do, but I just doubt it will be a
common thing to do.

> Let's say as an admin that I want to disable plymouth-quit.service (which is
> a static unit file and symlinked in /usr/lib… on the multi-user target).
> Without knowing the systemd internals, my natural intent would be to use
> "systemctl disable plymouth-quit.service" which is no-op in this case on a
> static unit enabled on the multi-user target with the symlink shipped by the
> package. This may be perceived as unnatural to him to have to use "systemctl
> mask" to disable it, or am I just being too pessimistic?

Right, I get it. In this case we should definitely warn when someone
tries to disable a statically enabled unit. We should suggest to the
user that this package is not meant to be disabled, but one can use
masking instead (voiding the warranty, etc, etc).

Cheers,

Tom