Originally posted by gamerk2
View Post
Generally speaking, when you hear about upstream projects relying on "systemd", it is these tools they relying on (usually logind and/or udev). And, generally speaking, when you hear about upstream projects "relying" on these tools, usually what they are relying on is a few well-documented dbus interfaces that any tool could conceivably implement. The reason that projects are relying on them is simple: it is a lot easier than rewriting the tools themselves from scratch, and nobody has stepped up to maintain alternatives. Any program that provides the necessary dbus interfaces would work.
Now there are cases where direct depencies on the systemd init system happen. For example, KDE plasma workspaces plans on using systemd socket activation under wayland to handle their services, because their home-grown service startup scrip has become a monstrosity that nobody dares touch not to mention greatly expand to support wayland. But again, conceivably any system that provides the necessary service handling tools would work. But nobody else provides such tools, and nobody is willing to do the work to port the script, so that is how things ended up.
The other case is daemons that are meant to be started and stopped by the init system. Those often ship configuration files or startup scripts for various init systems. In that case, it is up to the developers what init systems they want to take the time to support.
Comment