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. 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 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 implements a D-Bus interface, , and a library, , that programs can use to communicate with the daemon over the per-user-login-session message bus, to perform remote procedure calls (RPC). Both the library and the daemon use the sd-bus API of to implement bus client functionality.  also uses the sd-daemon API of  to pass service state information to systemd using the $NOTIFY_SOCKET protocol.


 * — 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 interface, and invoking the   method of its  object to take an inhibitor lock. The  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.


 * — 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.