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

[Ian Campbell]

On Fri, 2019-09-20 at 10:16 +0100, Mark Hindley wrote:
> 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.

Would it be any help at all of the "dbus client-ish" bits and the
"direct API-ish" bits of the two libraries were split up into two
separate libraries? i.e. would that allow the c/r/p replacement of one
of the two libraries (AIUI the API one is the more problematic) to be
pushed further up the dependency stack?

(my impression is no, but I thought I'd ask)

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

Has anyone investigated late dynamic binding using a stub library which
merely determines which init is running and then dlopens the
appropriate libsystemd0 of libelogind0 library and forwards the calls
to it?

I don't know if the dynamic linker could be coerced into doing the
selection automagically, in a way similar to how the hwcap stuff can be
used to pickup versions of libraries optimised for different classes of
processor. hwcap is provided by the kernel so I think can't be used
directly, but maybe there is a parallel mechanism somewhere?

Ian.