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.
