<snip>
More specifically this is how it should work: We'd have a directory /lib/systemd/system.preset/. By default it would be empty (or not even exist), which for simplicity reasons would mean "enable everything installed" (i.e. the Debian policy). Then, if distros or spins want to change what is enabled by default, they'd drop in a file (or multiple, which might be useful for a desktop spin and a graphical design spin where the latter is a superset of the former) in that directory. The file would be a trivial text file with lines like this:
<snip> disable avahi-daemon.service enable cups.service disable * </snip>
Then, we'd add a new command to "systemctl" called "systemctl preset". It would be equivalent to a "systemctl enable" if the unit file passed is listed in any of the preset files on lines prefixed with "enable", or be like a "systemctl disable" if it is listed with a prefix of "disable". Simple globbing would be supported. If no entry is found "systemctl preset" would be synonymous with "systemctl enable".
Generally I think this is a good idea, although the approach appears a bit simplistic and stuffing everything into one directory is probably not so great either. In another response there was mention of /etc/systemd to separate configurations, that's a step in the right direction. Still there would need to be some precedence rules if there are multiple files. For example if I have 3 files, a.preset, b.preset, and c.preset as follows: a.preset enable cups.service b.preset disable cups.service c.preset enable cups.service Is the service now enabled or disabled, probably depends on the processing order. But alpha sorting would not be a good choice as that is obviously locale specific and then has the potential of changing the behavior of the system as far as running services is concerned just based on the locale, that's just not correct. It appears that maybe having files named for services would be more intuitive to users, therefore one would have a cups.preset file as follows: cups.preset enable to enable or cups.preset disable to disable the service. Yes, from an implementation point of view this is more cumbersome and potentially requires the reading of many more files. Also this would make implementation of a default rule such as "disable all" more difficult. Another option would be to consider only two files, enable.preset and disable.preset. Enabled services are listed in enable.preset, disabled services are listed in disable.preset. The default rule can then be that enable wins, i.e. if a service is listed in both files it is enabled. Using the approach with only 2 files would allow easy implementation of default rules such as "disable all" an precedence is easy to explain. One could also consider making the precedence configurable, but then we'll get back into one distributions precedence is this and another's is that, which is not desirable. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead rschweikert@suse.com rschweikert@ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org