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

Lennart Poettering lennart at poettering.net
Fri Dec 5 07:42:18 PST 2014

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.


> 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 Poettering, Red Hat

More information about the systemd-devel mailing list