Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful

[Mark Hindley]

On Fri, Sep 20, 2019 at 09:06:57AM +0200, Laurent Bigonville wrote:
> Hello,
> 
> When I looked I elogind a while back I was able to build a package without
> having a public libelogind0, I basically had that in my debian/rules file:
> 
> # We only build the libelogind0 and libelogind-dev if we are building for
> # Devuan or its derivatives
> ifneq ($(shell dpkg-vendor --derives-from Devuan && yes), yes)
> export DH_OPTIONS=--no-package=libelogind0 --no-package=libelogind-dev
> endif
> 
> libelogind library is only needed for applications that want to interact
> with the daemon, in the ITP (#905388) bug I also noted that.
> 
> If I'm not mistaken, libsystemd (and libelogind) are using D-Bus to
> communicate with the daemon part, was it checked that the API used is
> compatible? Is there documentation of the differences, if any?

Yes, the APIs are the same (deliberately so).

> Bottom line, is libelogind even needed in the archive to achieve your goal
> of having an implementation of the login1 D-Bus API not requiring systemd as
> PID1?

Thanks.

I think you are correct that the login1 DBus API doesn't require libsystemd0 or
libelogind0. However some packages, notably policykit use the sd-login(3) API
which is part of libsystemd0 or libelogind0. Whilst the APIs, and symbol ABIs
are the same between the two libraries (with the caveats noted in the
libelogind0 package description) the implementations differ. I have been tolkd
int he past by elogind upstream that it is not possible for elogind to use
libsystemd0. For example libsystemd0 requires the concept of slices which
elogind doesn't have.

The only way I have got all of these components to work together on an elogind
systemd is to ensure everything uses libelogind0.

Mark