I'm currently using systemd on Manjaro and I'm planning on switching to Artix with OpenRC (Don't have anything against systemd, just want to try a new init system to broaden my horizons). I've read that a problem with non-systemd init systems is that some packages have hard dependencies on systemd, but the only example of this I could find is snap (from the following post).

Is there a way that I can list my currently installed packages which have a dependency on systemd and/or any of its related packages, so I can see if anything I am currently using won't work if I decide to use OpenRC instead?

  • The question is kinda unclear... Do you want to list all packages that depend on systemd/one of its services?
    – telometto
    Jun 27, 2022 at 12:38
  • This question seemingly makes no sense. Your new distro will have its packages not depend on systemd, otherwise they wouldn't use openrc in the first place. Not sure about what you're going to widen either, systemd is far superior to OpenRC in terms of features. You can think of OpenRC as a tiny subset of systemd. Jun 27, 2022 at 12:46
  • @ArtemS.Tashkinov : This has been a looong story. Starting with eudev. And code extracted from systemd. I was told that no one was eager to maintain eudev and since then (Gentoo for instance) swapped to systemd's udev. An therefore, udev can depend on systemd. ( gitweb.gentoo.org/repo/gentoo.git/tree/virtual/udev/… ) The same happening with elogind. The same happened to tmpfiles ( gitweb.gentoo.org/repo/gentoo.git/tree/virtual/tmpfiles/… ). The same will almost probably happen for elogind. (…)
    – MC68020
    Jun 27, 2022 at 17:16
  • (…) Yes ! At the time of writing, It is still possible to avoid this dependency (what I do blocking some pacakges) but you get to explicitly instruct portage to do so. Therefore I believe that some fresh-default installation will have packages depending on systemd. Of course, this is only a dependency on the code itself. The init system is not changed & remain openrc ! (Hurray!)
    – MC68020
    Jun 27, 2022 at 17:16
  • @telometto Yes, I phrased the original question incorrectly by accident, apologies.
    – Zsargul
    Jun 27, 2022 at 22:27

2 Answers 2


Though the question is a bit unclear, but assuming you want to list packages installed in your system that have systemd mentioned as Depends on, you can simply check that by pacman(since you are in manjaro).

pacman -Qi systemd | grep Required

In my case, it shows the following:

Required By     : android-udev  at-spi2-core  base  bluez-utils  colord  dhcpcd  dunst  iio-sensor-proxy  libcolord  libgudev  libinput  libmbim  libpulse  libwacom  mdadm  media-player-info  mkinitcpio  netctl  phodav  polkit  rtkit  sbupdate-git  subversion  swayidle  systemd-sysvcompat  transmission-cli  upower  vte3  xdg-desktop-portal  zram-generator

Does it means i would not be able to use these programs without systemd? NOT necessarily.

I am on arch and both arch and manjaro provides official support for a systemd based system. That means, the binary packages(that requires an init system, udev,syslog etc) in the official repositories are packaged keeping that in mind. Systemd fulfills these roles and hence if an arch package necessitate ( not really) the packager would mention systemd as a dependency in the PKGBUILD.

Let's take some example, in my case you can dhcpcd is listed as being dependent on systemd. That is for convenient, it doesn't really require an init system to start. you can just run from the terminal dhcpcd. The package maintainer has packed some systemd services with it so you can start dhcpcd with systemctl or have it launched by systemd after boot ( the same can be easily accomplished by a shell script run from your ~/.profile or other autostart script).

Another example is the libinput.libinput requires udev and udev is provided by the systemd package hence systemd is given as a dependency. artix have eudev and so official packages are packaged with eudev in mind.There are other alternatives to udev like suckless's nldev or mldev and it would only require few tweaks in a text config file to adapt to these different environments.

netctl(network manager) is listed as well, but i never needed to start it with its systemd service.I could just start it from ~/.profile(for example).

These are not hardcoded in the program code. The only difference ( from a layman's perspective ) is that different service manager uses different configuration syntax and location to store them.

Here's an excerpt from gentoo wiki. Meant for gentoo users but you get the idea:

Some upstream packages provide systemd unit files, to make them easier to install on systemd-based distributions and try make them work mostly out of the box, but don't otherwise have any heavier integration with systemd, or require any systemd-specific functionality. This sort of packages are not considered to have an actual dependency on systemd (neither 'soft' or 'hard'), and, according to the official ebuild policy for systemd, unit files follow the usual guidelines against small text files (bash completion, logrotate etc.) and ebuilds must not prevent their installation based on the systemd USE flag.


Unit files are harmless and do nothing if systemd is not installed, just like OpenRC service scripts do nothing if sys-apps/openrc is not installed. However, users that absolutely do not want systemd unit files on their machines, can add systemd's unit file paths to the INSTALL_MASK variable in /etc/portage/make.conf:

So, it is not that your packages(that are packaged for systemd) would break if you change from manjaro to artix, it is just that artix package maintainers would package their packages keeping their implementation in mind so there's no question of breaking anything generally.

even for snap,AFAIK, it requires systemd-tmpfiles to create and delete temporary files as well as for mounting the snaps/squashfs with systemd.mount. It is possible to detect those calls to snap and replicate that with your own custom scripts as this guy did


There are indeed some packages that may have hard dependencies on systemd or some of its services like Gnome desktop environment which depends on systemd-logind. But artix has a gnome-openrc iso in its testing (alpha ) stage .

  • 1
    it is not that your packages(that are packaged for systemd) would break if you change from manjaro to artix, it is just that artix package maintainers would package their packages keeping their implementation in mind so there's no question of breaking anything generally. Thanks for clearing this up, as I was not aware of packages working this way across different init systems.
    – Zsargul
    Jun 27, 2022 at 22:16

Your question does indeed make sense.

However, you just cannot expect reliably finding dependencies on systemd that would be needed under an openrc inited system, from a systemd-ized system.

Under an openrc inited system, it is indeed possible to find build dependencies on systemd for some packages. (some code from systemd is needed to build the package.) (udev, tmpfiles, elogind…)

The best I can suggest is that you start investigating from there : list of sys-apps/systemd reverse dependencies on gentoo and watch the lines starting with[B]

Of course for some packages, you could probably have alternatives offered to a systemd build dependency. Investigate deeper if you are interested.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .