The future of elogind/libelogind0

Mark Hindley mark at
Wed Oct 18 14:22:26 BST 2023

On Wed, Oct 18, 2023 at 01:29:38AM +0200, Adam Borowski wrote:
> Package: procps
> Version: 2:4.0.4-2
> Architecture: amd64
> Depends: libc6 (>= 2.34), libncursesw6 (>= 6), libproc2-0 (>= 2:4.0.4),
> »»» libsystemd0 (>= 254~rc1),
>     libtinfo6 (>= 6), init-system-helpers (>= 1.29~)
> And this dependency is not satisfiable by current version of libelogind0;

I think we have to grasp this issue and consider the future of elogind.

Upstream has been very inactive. The last commit was May 2023[1], the way the
code is derived from systemd is difficult and cumbersome and I am sceptical that
upstream has the desire and capability to continue maintenance that requires
keeping in step with systemd.

Within Debian, elogind (despite its flaws and limitations) still works, the real
issue is the ABI compatibility of libelogind0 and libsystemd0. As currently
deployed, we have no option than try to keep up with systemd. That is always
going to be uncomfortable and we are never going to be in control of that.

I think we need to consider other options. I have some theoretical avenues to
explore (in no particular order):-

 - Patch elogind to use libsystemd0 directly. This was considered previously[2]
   but rejected because elogind lacks, for example, scopes and slices. I don't
   even know if it is practical to fake, emulate or ignore these features.
 - Change to consolekit2. Whilst it is not a direct replacement, recently
   consolekit2 has been gaining a libsystemd compatibility layer[3] (AIUI still
   incomplete). I have packaged consolekit2 and it is waiting in NEW[4].

   2 possibilities occur to me here:-

     1) Use it directly: polkit can still be built to utilise consolekit and desktops
     	based on that are still viable. The mechanism for building a polkit
     	consolekit flavour would need to be resolved.

     2) Complete and use the nascent systemd compatibility layer 

 - Write a new logind implementation from scratch. Obviously a large
   undertaking, but traditional utilities and existing software (seatd[5],
   consolekit2...) may prove useful.

 - Other options I haven't considered...?






[5]  I already have a patch for xorg to use seatd to allow rootless startx
      without systemd, see

More information about the Debian-init-diversity mailing list