Bug#917431: debian-policy: virtual packages: logind, default-logind
On Sun, 30 Dec 2018 at 15:39:58 +0100, Adam Borowski wrote:
> On Sat, Dec 29, 2018 at 02:07:25PM +0000, Sean Whitton wrote:
> > Ideally, this would be reviewed and seconded by people working on init
> > stuff, so I'm not going to second it myself unless we don't get interest.
>
> I asked around, and got the following remark:
>
> Mark Hindley:
> } Could you just replace "providing logind API (over D-Bus and /run/)"
> } with something like "providing logind APIs (D-Bus and sd-login)" in the
> } upgrading checklist?
> }
> } /run/ is really not part of the API and nobody should be using it directly.
>
> Which makes sense -- directing people to wrappers and libraries instead of
> the files would be preferred. The less ad-hoc undocumented APIs are there,
> the better.
Maybe "via D-Bus and <systemd/sd-login.h>" or "via D-Bus and sd-login(3)"?
If a logind provider such as elogind doesn't result in the libsystemd
sd-login APIs working (at least as well as they would with the provided
logind version), would you consider that to be a bug in the provider?
I asked this earlier in the bug and didn't notice an answer (my apologies
if there has been one that I missed).
I ask because libsystemd users like dbus and policykit-1 cannot be linked
to both libsystemd and libelogind without compiling the daemon twice and
somehow arranging to run the right one for the installed system, which
I think is an undesirable level of complexity; for Debian, we should be
preferring the library that matches our default installation, which is
libsystemd. Derivatives like Devuan that don't have libsystemd at all
are of course free to link their libsystemd users to libelogind instead.
smcv
Reply to: