[systemd-devel] Another attempt: Making dependencies properly overridable

[Lennart Poettering]

On Mon, 16.02.15 16:19, Christian Seiler (christian at iwakd.de) wrote:

> Last time I talked about this here, there was a lot of confusion, so
> I didn't pursue it further. But I would really like to get this to
> work, but before I start with a patch, I'd like to explain what I'd
> like to do before working on it, to see if it works for you.
> 
> The semantics I'd like to see would be the following:
> 
>  - anything in /etc named exactly the same as in /usr/lib overrides
>    the latter, just as is already the case with units and drop-ins
> 
>      => allow masking of .wants/ and .requires/ with symlinks to
>         /dev/null (I think you were in favor of that)

Sounds good. I like. +1. Me gusta.

>  - additionally, postpone processing of dependencies in unit files
>    until the entire unit (and all drop-ins) have been read in
> 
>       For example, even without a drop-in:
> 
>       a.service:
>       [Unit]
>       Wants=b.service
>       Wants=
>       Wants=c.service
> 
>       After that, Wants should be set to c.service. Note that this
>       should NOT affect dependencies set in other ways, i.e. via
>       .wants/ directories or by dependencies of other services, this
>       should JUST alter what was specified in the unit itself.

I figure I can agree with this, too.

>      The general principle would be: you can drop stuff at the same
>      place it's defined. If it's defined as After= in a unit,
>      override it in a drop-in for that unit, if it's defined as
>      Before= in another unit, override it in a drop-in for the other
>      unit, and if it's defined in the filesystem via .wants/ or
>      .requires/, you can override it by masking it in the filesystem.
>      Only in the end will all remaining dependencies be combined to
>      make up the entire list of dependencies for that service.

Actually I'd probably be more liberal here and even allow dropping
deps created in the unit file with a .wants masking. The only thing i
would not allow is masking out deps on a unit that are actually
configure on another unit, as well as automatic deps.

I mean, so far the deps we set are combined from:

          unit file                          (1)
        + dropins                            (2)
        + .wants/ + .requires/ symlinks      (3)
        + automatic deps                     (4)
        + deps configured in other units     (5)

I'd allow unsetting deps configured in (1) from (1), (2) and (3). I'd
allow unsetting deps configured in (2) from (2) and (3). I'd allow
unsetting deps made in (3) from (3).

I would not allow unsetting deps made in (1,2,3) with (4) or (5), or
vice versa.

Lennart

-- 
Lennart Poettering, Red Hat