Package Service Presets
So far, whether a service is enabled or disabled after package installation is encoded in the %post scripts of the RPM, and decided globally for the entire distribution, ignoring the particular needs of spins. With the introduction of "presets" we'd like to remove this policy from the packaging scripts and place them in explicit "preset" files instead which can be different for the various spins, and even for individual systems.
- Name: Lennart Poettering
- Email: lennart at poettering dot net
- Name: Kay Sievers
- Email: email@example.com
- Targeted release: Fedora 18
- Last updated: 12-06-28
- Percentage of completion: 25%
Note: This is a resubmission of a feature for Fedora 17. In Fedora 17 the feature was declined with a referral to FPC to get the updated spec file scriplets accepted. This has happened now (see: https://fedorahosted.org/fpc/ticket/190 ), but FPC wants the feature accepted by FESCO too. Thus this resubmissions. FESCO, please accept this feature, so that this deadlock is resolved, thanks!
Starting with Fedora 16, systemd's "systemctl" command supports a verb "preset" that is used in a similar way to the well-known "enable" and "disable": "systemctl enable foo.service" causes a service "foo.service" to be enabled according to the installation information in the service file. "systemctl disable foo.service" undoes this work and disables a service. "systemctl preset foo.service" otoh acts either as equivalent of the former or of the latter, depending on information stored in preset files in /lib/systemd/system-preset/. In this directory a number of simple text files may be stored, consisting of lines such as "enable avahi-daemon.service", "disable rsyslog.service" and suchlike. There's support for wildcards, which can be used to match multiple units at once (useful for example for services which need both a .service and a .socket file) and for setting a global default.
Fedora will ship one default file /lib/systemd/system-preset/99-fedora.preset (maintained in fedora-release.rpm or so), and each spin another file like that on top. Files are read in alphabetical order, and the first matching line matters thus allowing spins to override the global fedora defaults. In addition, administrators can easily apply their own policy. For example, if they want a Debian-style "enable all" policy, they can easily do that by doing "echo 'enable *' > /etc/systemd/system-preset/50-foobar.preset". Packages are then updated to invoke "systemctl preset" instead of "systemctl enable" in %post in order to ensure that the preset file is honoured during package installation.
For further details on this, see:
A subproject of this feature is to provide generic RPM macros for the usual %post scriplets which do the enable/disable correctly using presets.
Benefit to Fedora
The lifes of Fedora spin maintainers become much easier: by dropping in a spin specific preset file they can override vanilla fedora policies.
The lifes of package maintainers become much easier: by using the new unified RPM macros the .spec file code is simplified a lot. Also, as the RPM macros will be shared with other distributions porting .spec files between distributions will be much easier.
Administrators can deploy their own policies overriding the Fedora defaults. For example, an admin with a Debian background can trivially enable Debian-style "always on" policy on a Fedora system which might be useful for desktop installations.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=630174 as admins can easily return to fedora defaults with the enable/disable status of services, by executing "systemctl preset" on the services in question.
The overall design is much cleaner, as mechanism in the RPM scriptlets is cleanly separated from policy in the systemd preset files.
systemd needs to be patched to support presets (DONE)
Generic RPM macros for applying preset information in %post (replacing the current scriptlets for enabling services on %post) need to be written (There's work from SUSE in this direction we can base our stuff on). This RPM macro should (for the beginning at least) live in systemd, in order to make it easy to share it between distros. (DONE)
The packaging policy needs to be updated in order to recommend usage of the macros instead of the scriptlets. (i.e. https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd ; FPC Posted, https://fedorahosted.org/fpc/ticket/190 )
Some core package needs to be updated to include the default fedora preset file which lists the very few services that may be enabled by default according to the current policy for "enable" and "disable *" to disable the rest. Probably should be fedora-release.rpm or a similar file. Basically, the data from https://fedoraproject.org/wiki/Starting_services_by_default needs to be turned into a compliant preset file.
Optional (can happen bit by bit over the subsequent releases): the various spins should be updated to include their own preset files.
Optional: The desktop live CD should probably ship its own preset file that differs slightly from the vanilla one.
Optional (can happen bit by bit over the subsequent releases): existing packages using systemctl enable/disable in the RPM scriptlets should be updated to use the new macro and thus honour the presets.
How To Test
After a default installation use "systemctl list-unit-files" to determine that only those services that are mandated by the policy are enabled, nothing else.
Drop in "enable *" in /etc/systemd/system-preset/50-foobar.preset and ensure that all packages enable their services by default from then on.
The user should not notice any difference, except when he is aware of the preset feature and decides to make use of it.
The package policy needs to be updated, in addition to the fedora-release.rpm.
FPC needs to accept https://fedorahosted.org/fpc/ticket/190
If package .spec files that have been upgraded to use the macro just revert back to invoking systemctl enable/disable directly everything should be fine again.
There's probably no mentioning necessary for this, as the fully benefits for users/admins only appear as soon as the .spec files and spins start making use of this feature, which will probably not happen for F17 right away. In F17 we just want to lay the ground work for this.