systemd support in packages

Gentoo has separate methods of handling obtrusive and unobtrusive systemd support in packages.

Obtrusive support is when systemd support:

collides with OpenRC support,

requires systemd being installed (e.g. linking to systemd libraries).

Unobtrusive support is when the package can support both OpenRC and systemd simultaneously without issues. Examples of unobtrusive support is portable, conditional code (i.e. runtime detection of init) and installation of unit files that are not used when systemd is not used.

For obtrusive conditional support Gentoo uses USE=systemd flag. For unobtrusive support, Gentoo enables relevant features or installs relevant files unconditionally. This aimed to ease switching to systemd and back by reducing the number of rebuilds.

Currently, by default, when using and running OpenRC, unobtrusive scenario implemented by means even when USE=systemd disabled and systemd ebuild masked, ebuilds installing units, sockets, etc. We find this policy controversial to user's needs.

Current state in Funtoo

Common changes

Funtoo overrides all udev virtuals to support only eudev as udev provider. This also implicitly blocks installing systemd or udev.

However, sys-apps/systemd and sys-fs/udev are not masked, so attempt at installing either of them will result in hard-to-understand blockers. Furthermore, USE=systemd is not masked, so users can enable it and be confused by the resulting blockers.

A number of packages install systemd-related files (the unobtrusive support from Gentoo). This includes:

no-systemd mix-in

After enabling the mix-in, new packages no longer install directly systemd-related files. However, files from existing packages are kept until all the packages that were installing them are rebuilt. The app-portage/install-mask (package not on wiki - please add) script can be used to find packages needing rebuild. Alternatively, the user can remove those directories manually.

It should be noted that removing /usr/lib/systemd may be unsafe. While this particular example is irrelevant to Funtoo, sys-fs/udev installs its udev daemon there and the daemon is used by OpenRC as well. Therefore removing the directory results in defunct udev. Other packages may follow a similar logic of installing system daemons in /usr/lib/systemd while the daemons can be used on OpenRC systems.

Possible changes for Funtoo

Consistent no-systemd setup by default

Since Funtoo does not support systemd, the explicit no-systemd mix-in seems redundant. Instead, the base profile could specifically:

mask alternative udev providers,

mask USE=systemd and other flags requiring systemd,

disable installing systemd files in safe way.

systemd units controlled via USE flags

It has been suggested that the ebuilds installing systemd-related files can gain USE=systemd even for non-obtrusive uses. To avoid forking numerous ebuilds, this could be done via modifying systemd.eclass. However, the eclass isn't suited for conditional install (and so aren't some build systems) and focuses on providing the install paths.

Instead, the eclass could be modified to return a well-known discard directory — and the directory would be either added to INSTALL_MASK, or stripped directly in Portage. However, I don't see any clear advantage over using standard install locations and stripping them via INSTALL_MASK.

Improved INSTALL_MASK handling

A semi-related potential improvement is to port the features provided by app-portage/install-mask (package not on wiki - please add) directly into Portage. This would specifically involve:

support for named sets of directories (alike USE flags), e.g. instead of /usr/lib/systemd/system /usr/lib/systemd/user …, you'd use @systemd,

options to cause rebuilds/binpkg reinstalls when the files effectively installed by package would change (due to change in INSTALL_MASK),