Re: Bug#915407: libpam-systemd: please add a virtual package "logind" to allow alternatives
Hello, On Mon 24 Dec 2018 at 05:37pm -0300, Felipe Sateler wrote: > 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. There seems to be a consensus (and this is not really controversial), to please file a bug against Policy with a patch to the virtual package list for seconding. -- Sean Whitton signature.asc Description: PGP signature
Re: Bug#915407: libpam-systemd: please add a virtual package "logind" to allow alternatives
]] Felipe Sateler Two minor typos. > The proposed virtual packages are: > > logind: a org.freedesktop.login1 D-Bus API implementation «an org…» > default-logind: should be provided by the distributions default logind > provider (currently pam-systemd) distribution's. Otherwise, this looks like a good idea to me. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Bug#915407: libpam-systemd: please add a virtual package "logind" to allow alternatives
On Mon, Dec 24, 2018 at 05:37:56PM -0300, Felipe Sateler wrote: > On Sat, Dec 22, 2018 at 5:33 PM Adam Borowski 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. Thank you for moving this forward! > > opt-in for every depender on libpam-systemd > > 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 Right. In the meantime, you can test using libpam-elogind-compat which is a hack that Provides: a real package. This lacks the opt-in effect, but outside of packaging metadata should work the same. > 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. Not sure if it's worth noting that the Provides must, and Depends can, be versioned. This allows requiring a certain level of the API. > Adam/other elogind maintainers, please clarify/improve wording if this was > somehow inaccurate. Looks good to me, thank you! Meow. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Ivan was a worldly man: born in St. Petersburg, raised in ⢿⡄⠘⠷⠚⠋⠀ Petrograd, lived most of his life in Leningrad, then returned ⠈⠳⣄ to the city of his birth to die.
Bug#915407: libpam-systemd: please add a virtual package "logind" to allow alternatives
Hi, On Sat, Dec 22, 2018 at 5:33 PM Adam Borowski 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