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.
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄⠀⠀⠀⠀
