On Mon, 06.05.13 19:29, Colin Guthrie (gm...@colin.guthr.ie) wrote: > >From the man page: > > > Additional units to install when this unit is installed. If the user > > requests installation of a unit with this option configured, > > systemctl enable will automatically install units listed in this > > option as well. > > What also happens however is that it if systemctl disable is called it > will also disable those units (certainly in my 195+patches build tho' I > can't see anything obvious in git what would fix this). The docs imply > it is one way and to actually be useful it's also sensible to have this > one way (as otherwise you may as well uses BindTo and skip the whole > [Install] section in one of the units).
"enable" and "disable" are supposed to be roughly symmetric. Or at least "disable" should always be able to undo what "enable" did (though might do a little bit more in some cases). This behaviour is absolutely crucial for package managers I am pretty sure. [Install] sections are about default installation suggestions, nothing else. With Also= the vendor can hence change what the default installation is, but the admin can ignore this entirely and choose with a few symlinks of his own what precisely he wants to enable and what not. BindTo= and suchlike are much stricter than this, since they are harder to override: the user actually has to copy the unit file and edit it for that... So, I am pretty sure we shouldn't alter the current behaviour of this. That said, I'd be open to merging a patch that makes interpretation of Also optional, for example via a --skip-also switch or so... Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel