[systemd-devel] [RFC] Preset Files

[Lennart Poettering]

On Wed, 06.07.11 00:51, Kay Sievers (kay.sievers at vrfy.org) wrote:

> 
> On Wed, Jul 6, 2011 at 00:42, Lennart Poettering <lennart at poettering.net> wrote:
> > On Wed, 06.07.11 00:26, Kay Sievers (kay.sievers at vrfy.org) wrote:
> >
> >> >> If "systemctl preset" is passed with unit names, those units would
> >> >> be enable/disabled as listed in the preset file. If no argument is
> >> >> passed all units would be reset to the preset defaults. (another
> >> >> long-sought feature...)
> >>
> >> We will require an argument. There will no 'change all services'
> >> logic.
> >
> > Uh?
> >
> > Actually, I do want a way how people can reset all service enable states
> > to what the vendor intended. And that should be "systemctl preset"
> > without arguments I believe.
> 
> That sounds pretty scary, it would usually just enable all installed
> services. This probably causes trouble with things like syslogs and
> login-managers that might be installed but only one of them should be
> enabled at the time. Not sure how that should really work.

Well the conflict problem is not specific to the "systemctl preset
without arguments" case. If you start from a naked system, and install
two syslogs using their RPMS, then both would attempted to be
enabled. Of course, we'd assume the second one would fail, right? The
same logic we should implement when "preset" is called with no args: the
enabling of the second unit if two units conflict would fail. Of course,
we'd have to come up with some semantics what first and what second
would be, but that should not be too difficult. Could be depending on
the order in the preset file if both are listed there. And if one isn't
listed there we'd prefer the one that is listed. And if neither is
listed we'd go alphabetically. That should be reasonably deterministic
and simple. So I see no big issue here. Conflicts suck of course, but it
isn't too hard coming up with an algorithm that makes them suck as
little as necessary.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.