Bug#925489: unblock: elogind/241.1-1+debian1

[Adam Borowski <kilobyte@angband.pl>]

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?
⠈⠳⣄⠀⠀⠀⠀