Hi, On Sat, Dec 22, 2018 at 5:33 PM Adam Borowski <kilob...@angband.pl> wrote:
> 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. [1] https://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt -- Saludos, Felipe Sateler