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

[Didier Roche]

Le 05/12/2014 14:52, Lennart Poettering a écrit :
> 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.

And I guess the default behavior (enable *) has a lower priority than 
overrides? (enable/disable). Also, I guess you concatenate all preset 
files as if it was a single one (ascii ordered?) to build that list.

So, retaking the display-manager (on the principle they all have: 
Alias=display-manager.service) example, that would mean:
* ubuntu-desktop would ship 99-defaults with:
enable lightdm

* If someone, install the gnome-ubuntu-desktop metapackage on the same 
install, they would get an additional preset file 50-gnome-ubuntu with:
enable gdm

And so, lightdm would be removed on a preset-all call as conflicting 
with gdm (due to sharing the same Alias) and having higher line number.

Sounds like a nice way to handle Alias. Happy to have a look at this.

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

Agreed, I already removed it from some ubuntu-only packages like 
whoopsie, xdiagnose… and I'm trying to investigate the right way to get 
a systemd-oriented solutions (while still being compatible with older 
init system for debian)
>
>> 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?

This is possible, but really not encouraged (due to some possibility to 
have unpacking or other intermediate states failing).
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?

Didier