Re: Should libpam-elogind Provide libpam-systemd ?
- Date: Fri, 2 Nov 2018 21:04:56 +0100
- From: Adam Borowski <kilobyte@xxxxxxxxxx>
- Subject: Re: Should libpam-elogind Provide libpam-systemd ?
On Fri, Nov 02, 2018 at 05:41:10PM +0000, Ian Jackson wrote:
> tl/dr: would this be wrong
> Package: libpam-elogind
> Provides: libpam-systemd
> and should there be a Conflicts too ?
This has been briefly discussed before: it's a quite bad idea to have
provides with same name as a real package. This works in Devuan where
there's no libpam-systemd, but in Debian we'd want something like:
Depends: default-logind | logind
or, if a specific version is needed:
Depends: default-logind (>= 126.96.36.1996) | logind (>= 188.8.131.526)
(as suggested by smcv a while ago).
I even prepared a set of packages with that dependencies, although they're
badly outdated by now:
deb http://angband.pl/debian logind main
deb-src http://angband.pl/debian logind main
wget -qO- https://angband.pl/deb/archive.html|apt-key add -
If you guys still think these deps are ok, tell me so and I'll refresh the
reverse dependencies in that repo.
> (emailing the systemd maintainers since that's Providing their package
> name, and also d-devel since I'm not sure what input others may have)
> In stretch this was handled on many sysvinit systems by systemd-shim.
> That is not really maintained - the version in sid right now is broken
> - and its approach means that it keeps breaking and is awkward to fix.
It never worked for me, even when it was "maintained". All -shim did was to
fulfill dependencies without actually bringing functionality such as suspend
/etc from the GUI. For that you had to recompile the Utopia stack against
consolekit. Elogind on the other hand does it ok.
> In buster it looks like we are going to try to do this by using
> elogind. elogind is not in sid yet but we already have a half-working
Its packaging is tailored for Devuan where there's no systemd to deal with.
On the other hand they're doing necromancy with consolekit which seems to be
a waste of time to me.
> The alternative to this Provides would seem to be an MBF requesting
> updates of all the dependencies. (Maybe some other virtual package is
I'm afraid this would be needed, per smcv's suggestion.
> (Our draft package ships libpam_elogind.so, but there are some
> difficulties with pam configuration ending up referring to both
> libpam_elogind.so and libpam_systemd.so and generating warnings, and a
> few packages seem to explicitly refer to pam_systemd.so, for instance
> lightdm's /etc/pam.d/lightdm-greeter. If we can't resolve that we may
> need to ship the pam module as libpam_systemd.so and that might
> involve Replaces as well as Conflicts.)
I have yet to test newer packages, apologies for not having done that yet.
⢿⡄⠘⠷⠚⠋⠀ A tit a day keeps the vet away.