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 libsystemd, this results in a build failure if that library is not present. Assuming the rest of the package is still worth it without these programs, a possible workaround would be patching the build system to make it conditionally build the  daemons, based on a  script option that a modified ebuild could turn on or off depending on the   USE flag state. The Gentoo ebuild installs OpenRC service scripts for other daemons though, in addition to upstream's service unit files.


 * — 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 . The package does not have a compile-time dependency on systemd, it uses the GDBus interface 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.1 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 set is also set.