I have been reading on this bug for a while now. On Tue, Sep 24, 2019 at 07:28:29AM +0800, Ian Campbell 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? > > (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? > [...]
While this would be a possible approach, this would also require that all applications currently linking with libsystemd need to link with something different, e.g liblogind. I think there was already some discussion about this general logind stuff a while ago. However, my personal feeling is, all the issues we have with packaging and dependencies now raise from a single source, namely that libsystemd integrates lots of - in my opinion completely - orthogonal functions in a single binary. E.g.: - Managing system init and services - Managing sessions - Managing temporary files - Managing devices ... This is the reason why libelogind has been massively stubbed to become api compatible and this is the reason why it is not possible to simply replace a function like "session management" with another solution. As of my thinking, the only proper solution here would be to kindly, well forcefully insist on systemd upstream to split their library by function and enforce them to link their own binaries properly with these libs. E.g. - libsystemd -> system init and services - libsystem-login -> sessino management - libsystem-udev -> .... ... Andreas
signature.asc
Description: PGP signature
