It's not a "niche" area. Without this, any modern GUI desktop environments are not installable with any pid 1 other than systemd. That'd be a massive regression that's certainly not acceptable (and it's caused by removal of a systemd component with a hard dependency).
This regression had a plan, with coded and tested patches by January 2018 (with a refresh + retesting in June, then November, December). In that plan, policykit packages had alternatives built against elogind. Yet patches did not get applied. Plan 2 was to dlopen() relevant libraries. Then, once a required one-line patch was finally applied to src:systemd (already in testing), policykit maintainers requested plan 3: to change libelogind0 to implement 100% of libsystemd0's ABI, so the alternative works at a different level: Plan 1: ├─ policykit-systemd ─── libsystemd0 ─── systemd │ └─ policykit-elogind ─── libelogind0 ─── elogind Plan 2: └─ policykit ─── libsystemd0 ─┬─ systemd │ └─ elogind Plan 3: └─ policykit ─┬─ libsystemd0 ─── systemd │ └─ libelogind0 ─── elogind (Consumers of logind API other than policykit go mostly via libpam-*d). With help of elogind's upstream, this request has been implemented. Of course, such a change has a pretty large debdiff. Yet, with no reports of regression within 12 days of testing in unstable, I believe it should be relatively safe. I'm not really happy with asking for an unblock for such a debdiff -- but if this can't go in, we'd need to use one of the other plans. Please say if you consider that to be better. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Did ya know that typing "test -j8" instead of "ctest -j8" ⢿⡄⠘⠷⠚⠋⠀ will make your testsuite pass much faster, and fix bugs? ⠈⠳⣄⠀⠀⠀⠀