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