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

Mark Hindley mark at hindley.org.uk
Tue Sep 24 10:05:36 BST 2019


Thanks for this.

On Tue, Sep 24, 2019 at 07:28:29AM +0800, Ian Campbell wrote:
> On Fri, 2019-09-20 at 10:16 +0100, Mark Hindley wrote:
> 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?

I think that is what we already have (if I have understood you correctly). The
dbus components are in systemd/elogind and the sd-*(3) APIs are in
libsystemd0/libelogind0. Or have I misunderstood?

> 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?

I think Adam Borowski suggested somthing similar a while ago as an option, but I
am not aware of anything more than an idea.

I also experimented with LD_PRELOAD a while ago. But it felt very hackish.


More information about the Debian-init-diversity mailing list