Lennart Poettering wrote: > <snip> > disable avahi-daemon.service > enable cups.service > disable * > </snip>
I suppose evaluation stops as soon as an entry matches. So as Distro we could have e.g 99-default "disable *" as default policy. > - The RPM post macro would always call "systemctl preset" for the units > passed, and never anything else. What happens if the preset lists the service as enabled but the admin has disabled it manually? Will a package or distro upgrade re-enable the service? I suppose systemd needs to store somehere whether a preset was already applied for each service. > - The reason why we'd implement "enable-by-default" instead of > "disable-by-default" if no preset file is around is simply the idea > that having to install stuff that is not needed is already a failure > in itself, and ideally people who want to disable a service would just > "rpm -e" it. That's not quite the case, think of e.g. openssh where you may want the client but not the server¹ or mysqld which is used by kde per user or avahi where you may want avahi-daemon but not avahi-dnsconfd :-) However, that ok as long as we can put a "disable *" by default somewhere. > Anyway, this of course requires some buy-in from the distributions, so > I'd like to ask the distro maintainers for comments on this. Do you > think this would be useful to you? Any other suggestions, ideas? Good idea in general. Checking simple files instead of trying to make sense of shell code in %post also makes life easier for rpmlint. cu Ludwig [1] back in the days when we nearly got lynched for disabling sshd by default we explicitly decided not to split the package in client and server. -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel