On Wednesday, July 06, 2011 21:28:21 Robert Schweikert wrote:
<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:
The order is alphabetically if there are several files, like udev does it today. So, I guess we add a 99.openSUSE rule that does "disable *" as the last one.
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.
The locale systemd runs under is the C locale - and if you use numbers, everything is fine.
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.
I don't understand what you're getting at.
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.
This is exactly distribution specific files. This will allow a vendor to ship different preset rpm packges (that might conflict with each other), e.g. a server one, a desktop one, a paranoia one... The precedence is defined, Andreas -- Andreas Jaeger, Program Manager openSUSE aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org