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

[Didier Roche]

Le 05/12/2014 16:42, Lennart Poettering a écrit :
> On Fri, 05.12.14 16:02, Didier Roche (didrocks at ubuntu.com) wrote:
>
>
>
>> This would also only "fix" the newly installed case, not the upgrade with
>> new distro defaults or various purge vs remove ones. That's why I think some
>> kind of previous state db can help getting all those requirements met as you
>> propose, and doing some comparisons between states (only when they deviated
>> from defaults).
>> Then, we can run preset on packages that matches previous defaults (meaning:
>> where the admin didn't override the default choice) as a dpkg trigger (when
>> new units are installed/upgraded and on a new/updated preset file shipped).
>> Would that makes sense?
> Not sure I grok what you are proposing. I'd be very careful with
> keeping yet another layer of service enablement states (even if just
> as "history") in systemd upstream.

I can clearly understand why you don't want to have a database of 
previous default enablement status. (that's what debian/ubuntu is doing 
right now in /var, having a bunch of symlinks to keep default state).

There are 3 cases that we want to have supported (ideally with preset-only):

1. upgrade with default policy change:
* foo.service is enabled in a target (with an [Install] section). Preset 
says 'enable *' (== no preset stenza) by default.
* sysadmin didn't enable/disable it.
* an upgrade of a package (not necessarily the package containing 
foo.service) ships a new preset file with "disable foo.service"
-> We should have then foo.service disabled as per preset choice.

2. upgrade with dependency change:
* foo.service was WantedBy=bar.target. It was enabled by default.
* sysadmin didn't enable/disable it.
* After an upgrade, the unit contains WantedBy=baz.target (still enabled 
by default)
-> We have it still enabled by enabled (as per preset choice), with 
.wants symlink from baz.target

 From those 2 cases, we could say: "just run systemctl preset on every 
package upgrade or preset change", however, there is as well this case:

3. upgrade with default changes, but sysadmin overrides:
* foo.service was WantedBy=bar.target. It was enabled by default.
* sysadmin run systemctl disable foo.service (or mask it)
* After an upgrade, the unit contains WantedBy=baz.target (still enabled 
by default preset policy)
-> We shouldn't have foo.service enabled back as the admin did disable it.

That's why I was evocating keeping a previous state database to detect 
"previous default state == current state", and only run preset on the 
package in that case (and new installs).

Is this more clear? Any other idea of on an elegant way of handling 
those without having the previous state database? (in an upstream 
compatible way, if possible)
Didier