On Fri, 05.12.14 10:58, Andrei Borzenkov (arvidj...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
