Bug#940034: elogind and the release team block
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. ⢿⡄⠘⠷⠚⠋⠀ ⠈⠳⣄
Bug#940034: elogind and the release team block
> "Adam" == Adam Borowski writes: Adam> 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. Adam> We _did_ use libpam-systemd in the past. This code was Adam> working and tested, by January 2018 (using consolekit not Adam> elogind by then), then a different version (with elogind), Adam> well-tested in Devuan then finally submitted in November 2018. Adam> The difference is the point the alternative happens at: As Mark pointed out I meant libsystemd0. That is, to make the convergance point the dbus APIs etc. --Sam
Bug#940034: elogind and the release team block
Julien, On Wed, Sep 11, 2019 at 03:07:51PM +0100, Mark Hindley wrote: > I would hope we can all accept those. If so, there is no requirement for a > manual block: at the moment there are RC bugs which prevent migration. If or > when they are resolved migration can occur based on the release teams policy > in > effect at that time. I see you have removed the block whilst I was writing this. Thank you. Mark
Bug#940034: elogind and the release team block
Sam, Thanks 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. Thanks for helping to clarify that. [snip] > 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. This was from my discussions with elogind upstream, mainly in the context of #923244. We considered the possibility of linking elogind against libsystemd0. However, it was felt that the implementations were sufficiently different to make that unfeasible. My understanding is that elogind doesn't have a concept of slice simply because it doesn't require them. It just maps pids, sessions and users. But I am happy to go back to them and ask again. > Now you've got someone arguing that the providing libpam-systemd and > conflicting with libpam-systemd is problematic. Do you mean libsystemd0 here? > And I'll admit that it is definitely a problematic approach. > I realize that you talked it over with the systemd maintainers and while > they didn't quite agree, my reading of their message was fairly > sympathetic. > > So now you've got conflicting requirements coming from multiple > directions. > > I really don't see a way forward besides getting enough of the right > parties involved to understand the issues and come up with a solution > that balances the trade offs across multiple packages. > > I'm sorry that you've been placed in this position. No worries. Thanks for your help. My suggestion is based on the following premises:- - We are currently early in the bullseye cycle. There seems to me to be no better time to allow a wider audience to test elogind and report problems. I can certainly understand reluctance to test this later in the cycle. - The existing RC bug handling is sufficient on its own to control whether elogind should be in testing. - If problems are found with elogind either directly or indirectly, please submit bugs, RC status if it is warranted, and I will be happy to deal with them. I want elogind to be as good as it can be both for its users and for people who choose not to use it. I would hope we can all accept those. If so, there is no requirement for a manual block: at the moment there are RC bugs which prevent migration. If or when they are resolved migration can occur based on the release teams policy in effect at that time. Does that seem reasonable? Mark
Bug#940034: elogind and the release team block
Dear Mark: 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. I suggested that he might open his concerns as an RC bug on the package, because that would regularize the situation. Please do not just downgrade an RC bug opened by a member of the release team. I think the release team would be entirely justified in blocking your package or removing it at that point. Unfortunately, it sounds like you are in a bad situation. The systemd maintainers are telling you that you need to provide libpam-systemd. 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. Now you've got someone arguing that the providing libpam-systemd and conflicting with libpam-systemd is problematic. And I'll admit that it is definitely a problematic approach. I realize that you talked it over with the systemd maintainers and while they didn't quite agree, my reading of their message was fairly sympathetic. So now you've got conflicting requirements coming from multiple directions. I really don't see a way forward besides getting enough of the right parties involved to understand the issues and come up with a solution that balances the trade offs across multiple packages. I'm sorry that you've been placed in this position. --Sam
