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

[Lennart Poettering]

On Fri, 05.12.14 10:58, Andrei Borzenkov (arvidjaar at gmail.com) wrote:

> That's not how I actually understood it. enable/disable still applies
> only to units with [Install] section as it is now. Just that
> 
> systemctl disable
> 
> means that if there are links in /usr/lib, they are masked in /etc.
> I.o. unit foo.service is enabled if
> 
> 1. [Install] section exists
> 2. Links from [Install] section are present either in /usr/lib or
> in /etc
> 
> unit foo.service is disabled if
> 
> 1. [Install] section exists
> 2. There are no links from [Install] in /usr/lib or /etc *OR* there are
> links in /usr/lib which are masked in /etc.
> 
> Units without [Install] section remains static as they are today.
> 
> This will allow to cleanly separate distribution default (/usr/lib) and
> admin decision (/etc). Also this will allow systemctl list-unit-files to
> supply information like
> 
> enabled (default)/enabled (admin)
> 
> depending on whether link in /usr/lib or /etc exists.
> 
> IOW - /usr/lib keeps default state and /etc keeps overrides for default
> state.

Hmm, I figure I could live with such a scheme. Not enthusiastic about
the idea, but I see the value, hence I'd merge a good patch for it.

Masking dependency symlinks is certainly OK, the part I am not overly
enthusiastic about is the changes to "systemctl enable" and "systemctl
disable" you propose. But given that behaviour of these commands
wouldn't change unless you actually have symlinks in /usr + [Install]
in the unit file, which doesn't really happen so far, I am fine with it.

Lennart

-- 
Lennart Poettering, Red Hat