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

[Lennart Poettering]

On Fri, 05.12.14 16:02, Didier Roche (didrocks at ubuntu.com) wrote:

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

Yeah, the default policy of "enable *" would have the largest possible
line number, so that any other line number wins.

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

correct.

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

Would love to take a patch for this.

> >>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?

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.

Lennart

-- 
Lennart Poettering, Red Hat