Hard dependencies on systemd

While some people might intuitively think that software packages should not generally depend on a specific init system, systemd itself is a large package that not only implements an init system, but also provides a number of other executables (,, , , , , , , etc.), libraries , a PAM module and a UEFI boot manager , among other components. So any other package that needs any of these components, even if it is just one, would pull as a dependency.

This article contains Article description::a (possibly partial) list of packages in Gentoo's repository that unconditionally require [[systemd]], i.e. that unconditionally list sys-apps/systemd in one or more of the corresponding ebuild's xDEPEND variables, thereby making systemd a 'hard dependency'.

Packages

 * — This package includes three daemons,, and , that extract core dumps, oopses and Xorg crashes, respectively, logged in systemd's journal. These tools are useless on Gentoo without systemd; however, the package's build system builds them unconditionally, and because they access the journal using the sd-journal API of , this results in a build failure if that library is not present. Assuming the rest of the package is still worth it without these daemons, to avoid the dependency the build system would have to be patched to conditionally build them based on a  script option, and the ebuild would have to be modified to enable or disable the option based on the state of the   USE flag. The ebuild installs OpenRC service scripts for other daemons though, in addition to upstream's service unit files. Also, several other programs use , so they gain an indirect dependency on  through that library (see below). In particular, those that produce log messages instruct  to log to the journal , expecting the administrator to configure  to forward messages to syslog, instead of logging to syslog directly . A decision that would have to be reverted (or  would have to be patched to make   a synonym of   if journal support is disabled at compile time).
 * — This package provides a daemon,, that requires systemd running as PID 1 to manage snap packages. Since snap packages are files, the daemon uses systemd's  program to mount and unmount snap package archives. While the daemon makes calls to  to perform these functions, it does not specify the path to its executable. A potential workaround would be to substitute  with a custom program in its place to intercept the daemon's calls to the program.


 * — This package provides a library,, with logging functionality among other things, including logging to systemd's journal. It does so by using the sd-journal API of . To avoid the dependency, the library and the build system would have to be patched to make the feature, which is useless on Gentoo without systemd, a compile-time option, and the ebuild would have to be modified to enable or disable the option based on the state of the  USE flag.


 * — This package provides a daemon,, that expects to be launched and supervised by a process running as a user instance  (i.e. ). It does so by installing a service unit file, , in . It has no other runtime dependency on systemd, and no compile-time dependency on it.


 * — This package provides a GTK+ 3 program,, that inhibits the low-level handling of the hardware lid switch by communicating over D-Bus with a process that implements the org.freedesktop.login1.Manager interface, and invoking the  method of its  object to take an inhibitor lock. This D-Bus interface is implemented by , but also by elogind, so it is not clear if this package couldn't also work with . It does not have a compile-time dependency on systemd, it uses the GDBus API of GLib.


 * with the  USE flag set — This package provides a daemon,, that, in combination with a second process that meets certain specifications, called the controller, implements a D-Bus message bus daemon, just like the  program from the D-Bus reference implementation . It also provides another daemon, , that can act as a controller for , and is built if the   USE flag is set. Because  needs a controller to be usable, this is the ebuild's default setting (i.e.  ).  and  together aim to behave in a way that is fully compatible with , except in several occasions where it deviates. While  does not have any dependency on systemd,  has lots:
 * Its code is structured as an event loop, implemented with the sd-event API of . Events that the loop handles are received signals, received D-Bus messages, process terminations, and changes in directories that contain configuration files (e.g. ) and service files (e.g.  and ), and are monitored via inotify watches.
 * It uses the sd-bus API of to implement communications over the message bus, and communications with.
 * It uses the sd-daemon API of to receive the message bus' file descriptor from systemd, and to verify that it corresponds to a listening, stream mode UNIX-domain socket.
 * It also uses the sd-daemon API to notify systemd when it is ready to provide the service, and when it is reloading.
 * It uses the the sd-id128 API of to retrieve the system's machine ID.
 * At runtime, it tries to connect to 's socket,, to log both its messages and 's to systemd's journal.
 * At runtime, it doesn't execute activatable services' associated programs itself like does. Instead, it expects a  process to be connected to the message bus, and asks it to execute the programs by creating transient service units for them, using systemd's org.freedesktop.systemd1.Manager D-Bus interface. This is one of the documented deviations.


 * — This package provides a bash script,, intended to be periodically executed with a  argument, and a timer unit file and accompanying service unit files to implement that with systemd. The script is likely usable on Gentoo without systemd regardless, e.g. with explicit cron setup by the user, provided the XDG_RUNTIME_DIR environment variable is appropriately set as per the XDG Base Directory Specification . The  command also uses  to show the status of its supplied units as part of its output ("Systemd service is currently active", "Systemd resync service is currently active"), which is meaningless without systemd. Running the unmodified script would be ugly because of the shell's "command not found" error messages instead of the intended output, but otherwise nonfatal. Cosmetic patches could be applied to suppress that part of the output, and to fix other error messages that suggest systemd commands to the user in order to fix the situation that caused the error.

Packages that formerly had a hard dependency on systemd

 * — For versions 3.28 and earlier, the GNOME desktop environment contained components that required (among them, notably, its display manager, GDM). However, as of version 3.30, Gentoo's packaging of GNOME allows it to work once again with sysvinit + OpenRC as the init system . This is achieved through elogind; non-systemd GNOME profiles (i.e. those with 'gnome', but not 'systemd', in their name) set the   USE flag so that packages pull sys-auth/elogind as a dependency instead of sys-apps/systemd. Some GNOME packages, though, still unconditonally pull sys-apps/systemd, and are explictly listed above.


 * with the  USE flag set (i.e. ) — For versions 3.28.0 and earlier, Mutter's native (KMS) backend used to require . Building the native backend is optional, and enabled if the   USE flag is set. As of version 3.28.1, the native backend can alternatively be built with elogind, and Portage will do so if the   USE flag is also set.