Bug#940034: elogind and the release team block

Adam Borowski kilobyte at angband.pl
Wed Sep 11 15:48:53 BST 2019


On Wed, Sep 11, 2019 at 09:15:58AM -0400, Sam Hartman wrote:
> I reached out to jcristau to talk about his block hint.
> Based on our IRC discussion, it sounds like he was having trouble
> bringing himself to remove the hint presumably because he doesn't think
> the broader issue was being dealt with.

> The systemd maintainers are telling you that you need to provide
> libpam-systemd.

We _did_ use libpam-systemd in the past.  This code was working and tested,
by January 2018 (using consolekit not elogind by then), then a different
version (with elogind), well-tested in Devuan then finally submitted in
November 2018.  The difference is the point the alternative happens at:

PROGRAM -> policykit -> libpam-XXX -> logind

A)
PROGRAM -> policykit-systemd -> libpam-systemd -> systemd
        |
        `> policykit-elogind -> libpam-elogind -> elogind

B)
PROGRAM -> policykit-systemd -> libpam-systemd -> systemd
                             |
                             `> libpam-elogind -> elogind

C)
PROGRAM -> policykit-systemd -> libpam-systemd -> systemd
                                               |
                                               `> elogind

The Jan 2018 version used A; the Nov 2018 version used C.  Another debated
option was B with dlopen.  Finally (shortly before Buster freeze), it was
requested to make libelogind fully ABI-compatible with libsystemd -- which
elogind's upstream helped implement, but that version was not allowed into
Buster.  And now, we have that replacement problem.

Thus... which way do you want?

> Actually, they would prefer that you create an elogind that mirrors
> enough of the interfaces that you can just use libpam-systemd.  You said
> that would not work, explaining that elogind for example doesn't have a
> concept of slices.  You never clearly articulated why it couldn't
> emulate slices enough to pacify libpam-systemd.  I don't know if it is
> just that work hasn't been done or if it would be a bad idea for some
> reason.

Making elogind implement every single feature of systemd would effectively
make it systemd.  That's not the point.

If I had infinite tuits, I'd implement a clean unix-logind that stubs the
API to good old POSIX functionality -- if you type "who" on a 1990s' system,
you'll already get the same thing the logind idea reimplements.  Unlike
elogind which is a trimmed copy of systemd, that'd make slices completely
out of question.  Same applies to any logind for non-Linux or non-GNU.

I'd say we want the stubs to be as lean as possible (for simplicity, less
moving parts, smaller attack surface, etc), rather than to implement every
single add-on.  If I wanted systemd, I know where to find it (although it
doesn't even boot on my main desktop).


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Your snowflakes have nothing on my socks drawer.
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄⠀⠀⠀⠀




More information about the Debian-init-diversity mailing list