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

[Lennart Poettering]

On Fri, 05.12.14 11:06, Didier Roche (didrocks at ubuntu.com) wrote:

> >>It seems maintaining this list in sync for all flavors would be a growing
> >>pain (this is a positive effect of the disable by default: you don't have to
> >>maintain such a list), or do you think we can come with something
> >>better?
> >Hmm, yuck. No good suggestion. I figure this problem doesn't exist
> >with the fedora default of everything is disabled by default...
> >
> >All open to ideas...
> 
> Can we maybe extend the preset dictionary by having an alias (or
> alias-default) keyword taking a pair of arguments, like:
> alias display-manager.service lightdm.service
> 
> Then, the preset command, for each alias, will stop at the first one it
> encounters. If the service doesn't exist, it's a noop, if it's there, it
> enables (--force in case something else was enabled for that Alias?)
> lightdm.service. It means of course that lightdm.service should contain:
> [Install]
> Alias=display-manager.service
> 
> or preset would then generates a warning.

So far this is not how presets work: they are just a database you pass
in as key a service name, and it tells you whether to enable it or
not, in a simple boolean way. It is something where you pass in the
name of a unit you want to enable/disable, and after you got that, you
do that, but you do not verify again the individual steps
enabling/disabling precisely entail.

It also is currently entirely stateless: you could in theory ask a web
server for such a preset question, and it will always tell you the
same answer, because it does *not* take your local configuration and
set of packages into consideration... This kind of "disconnected" logic
I'd really like to keep.

Hmm, what about this proposal:

Whenever the preset db is queried we'll no longer just return the
verdict boolean, but also a numeric overall line number, of the line
we found the verdict on. Then, when "preset-all" is invoked, we
determine all the operations to execute for everything. Then, before
applying them, we check if there are any conflicting operations. If
so, we remove the ones with the higher line number.

In effect this would mean: if you list to DMs as "enable" in the
preset file, and both are to be installed, then the one that is
enabled "earlier" will win in case of "preset-all". To me this appears
quite a natural extension of the logic already in place.

> >How does this all precisely work on  on ?
> 
> Most of them shipped a conffile like /etc/default/<service_name> file with
> an ENABLED=true/false keyword. This doesn't really map in the systemd world
> (repetition of enablement/disablement states)
> * "apt-get remove" keeps conffiles
> * "apt-get remove --purge" deletes them.
> * When an upgrade occurs:
>   - if the package conffile didn't change -> kept with the modifications if
> any
>   - if the package conffile did change -> infamous debconf prompt about "a
> maintainer configuration file changes, do you want to apply maintainer
> changes/keep as it is/see the diff…"
> 
> That's how all those use cases are handled on sysvinit.
> Of course, we could introduce that back with ExecStartPre=`grep …` but well,
> 2 places (systemd symlinks + a /etc/default/ file) to decide one thing isn't
> really appealing nor wanted :)

To be honest I find the entire stuff with ENABLED=true/false really
questionnable, I think it would be agreat step ahead to get rid of
it. (But then again, I cannot make Debian's decisions there...)

> Only preinst can (getting the "install" or "upgrade" argument), not postinst
> (getting "configure" in both case). And we need to run the preset/enable in
> postinst (meaning: after unpacking).

This sounds quite a limitation. Maybe you can keep a couple of touch files
in /var/lib/ somewhere where you store whether you already applied
"systemctl preset" before?

Lennart

-- 
Lennart Poettering, Red Hat