FLOP:No-systemd system

Created on

2015/02/09

Original Author(s)

Mgorny

Status

Reference Bug

FL-2091

Funtoo Linux Optimization Proposal: No-systemd system

How systemd sneaks in into Funtoo, and possible solutions for removing it.

State inherited from Gentoo

udev implementations

Gentoo has three udev providers:

• sys-apps/systemd provides udev as a part of standard systemd installation,
• sys-fs/udev provides the systemd variant of udev decoupled from systemd, with some Gentoo patches,
• sys-fs/eudev provides the Gentoo fork of udev from before it was coupled into systemd.

The existence of those providers is acknowledged by the following virtuals, see http://www.funtoo.org/Virtual_Packages :

• virtual/udev,
• virtual/libudev,
• virtual/libgudev.

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.

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:

• systemd units (services) in /usr/lib/systemd/system installed by multiple packages,
• binfmt descriptions in /usr/lib/binfmt.d (dev-dotnet/pe-format, used by OpenRC as well),
• modules loaded at boot in /usr/lib/modules-load.d (not yet observed, TODO: check if OpenRC uses it),
• sysctl settings in /usr/lib/sysctl.d (not yet observed),
• declarations of system users & groups in /usr/lib/sysusers.d (not yet observed outside systemd),
• tmpfiles.d in /usr/lib/tmpfiles.d installed by multiple packages (used by OpenRC as well),
• potentially other configuration files in /usr/lib/systemd (sys-power/upower),
• potentially any other executable in /usr/lib/systemd (unsupported sys-fs/udev), sometimes used outside systemd as well.

no-systemd mix-in

The no-systemd mix-in additionally:

• masks sys-fs/udev and sys-apps/systemd,
• adds INSTALL_MASK to remove systemd files in /usr/lib/systemd (and the incorrect /lib/systemd directory).

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 No results 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:

1. mask alternative udev providers,
2. mask USE=systemd and other flags requiring systemd,
3. 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 No results directly into Portage. This would specifically involve:

1. 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,
2. options to cause rebuilds/binpkg reinstalls when the files effectively installed by package would change (due to change in INSTALL_MASK),
3. emaint function to directly remove files in directories added to INSTALL_MASK.