Web lists-archives.com

Bug#915407: libpam-systemd: please add a virtual package "logind" to allow alternatives


On Sat, Dec 22, 2018 at 5:33 PM Adam Borowski <kilobyte@xxxxxxxxxx> wrote:
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
    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.

[1] https://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt

Felipe Sateler