Debian May Need To Re-Evaluate Its Interest In "Init System Diversity"

Debian Project Leader Sam Hartman has shared his August 2019 notes where he outlines the frustrations and issues that have come up as a result of init system diversity with some developers still aiming to viably support systemd alternatives within Debian.

Stemming from elogind being blocked from transitioning to testing and the lack of clarity into that, Hartman was pulled in to try to help mediate the matter and get to the bottom of the situation with a lack of cooperation between the elogind and systemd maintainers for Debian as well as the release team. Elogind is used by some distributions as an implementation of systemd's logind, well, outside of systemd as a standalone daemon. Elogind is one of the pieces to the puzzle for trying to maintain a modern, systemd-free Linux distribution.

Various issues were raised that are trying to be worked through albeit many Debian developers face time limitations and other factors like emotional exhaustion. Hartman noted in his August notes, "I think we may be approaching a point where we need to poll the project--to have a GR and ask ourselves how committed we are to the different parts of this init diversity discussion. Reaffirming our support for sysvinit and elogind would be one of the options in any such GR. If that option passed, we'd expect all the maintainers involved to work together or to appoint and empower people who could work on this issue. It would be fine for maintainers not to be involved so long as they did not block progress. And of course we would hold the discussions to the highest standards of respect."

The DPL went on to add, "Things may have changed since our last GR on the issue. There are 1033 non-overridden instances of lintian detecting a service unit without an init.d script. The false positive rate seems high especially for packages that break their systemd integration. There's been discussion on debian-devel about moving to using service units as the default rather than init scripts. So perhaps sysvinit and init scripts have had their chance and it is time to move on. We could move away from init scripts as the default representation. We could stop caring about sysvinit (which isn't quite the same thing but is related). That would leave non-linux ports in an unfortunate position. But right now there are no non-linux ports in the main archive. So perhaps we don't even care about that. Again, a change, but a change that we can ask ourselves if we are ready to make. "