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

[Andreas Messer]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://www.chiark.greenend.org.uk/pipermail/debian-init-diversity/attachments/20191006/d96c5efc/attachment.sig>