On Wed, 06.07.11 09:33, Ludwig Nussel (ludwig.nus...@suse.de) wrote: > > 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.
Correct. > > - 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. No, we'd consult the preset only on initial package installs. On upgrades we'd not change enablement status. > > - 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. I think many distros split up avahi, mysql and openssh to deal with this, an I think that's the right approach. Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel