On Sat, 06 Jan 2018 at 05:18:09 +0100, Simon Richter wrote: > We still need a non-systemd ecosystem for everything that is out of > scope for systemd.
If this is important to you (and when I say "you" here I mean everyone who agrees with that statement, not just you personally), then src:sysvinit and the ecosystem around it could really benefit from your help. initscripts currently has an RC bug open, its most recent maintainer upload was almost a year ago, and most of the uploads in the last couple of years were from systemd maintainers keeping it on life-support; systemd-shim is unmaintained upstream and in Debian; cgmanager is unmaintained upstream and RFA in Debian; and libnih is unmaintained upstream and in Debian (and currently uninstallable and fails to rebuild, although there's a patch in the BTS for that). In the longer term, elogind (a standalone fork of systemd-logind) might well be a more sustainable way to provide systemd-logind APIs on sysvinit-booted systems than the current approach of combining the current systemd-logind with systemd-shim, an incomplete emulation of the systemd manager (pid 1) that needs to keep up with whatever manager APIs logind currently makes use of. After all, it seems more likely that third-party software can cope with an old version of the logind APIs than that systemd-logind can cope with an old version of the systemd manager API, when logind and the manager are normally part of the same source tree and so are upgraded together. Either way, if you want sysvinit (and the stack around it) to continue to be supported, it's necessary for someone who thinks the same way to do the work to support it. Expecting the rest of Debian (and in particular the systemd maintainers, ironically) to keep propping up sysvinit is not really sustainable. smcv