Hi!
Could you please either take this patch or propose a different approach?
I have received no feedback other than a brief unconclusive remark on IRC.
Sorry for the radio silence. Let's try to remedy that.
The clock for Buster is ticking; to get any testing we'd need to act soon.
Not only this approach has been proposed by one of systemd maintainers
(granted, more as a brainstorming than a definitive proposal from your team)
but it also has seen actual testable packages since January.
I admit that my own testing was extremely uneven -- mostly restricted to
environments I personally use -- but as the idea is opt-in for every
depender on libpam-systemd, packages no one claims to have tested simply
won't be usable without systemd. Just like they're right now.
This is a good feature of the proposal: it requires explicit opt-in by reverse dependencies.
Thus: if package X and Y need APIs that elogind provides, they'd be changed
to:
Depends: default-logind | logind
while package Z that needs a "bring-me-pink-pony" function will not.
I (not speaking for the whole team), have no objection to this patch. However, it was pointed out to me that virtual packages require policy updates[1], first starting as a debian-devel discussion. So I'm starting this now
The proposed virtual packages are:
logind: a org.freedesktop.login1 D-Bus API implementation
default-logind: should be provided by the distributions default logind provider (currently pam-systemd)
Background: currently libpam-systemd provides two features currently used by third parties: one is the necessary hooks to start the systemd implementation of login1. The second is hooking up the systemd --user service manager. This virtual package attempts to disentangle the two so that packages that only require logind can use an alternative implementation.
Adam/other elogind maintainers, please clarify/improve wording if this was somehow inaccurate.