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
