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

[Ian Campbell]

On Tue, 2019-09-24 at 10:05 +0100, Mark Hindley wrote:
> Ian,
> 
> 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?

Probably I have, I thought the dbus client side stuff was in
libsystemd0/libelogind0 too.

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

Might be worth a PoC?

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

Yeah. that's probably not the way to go.

Ian.