The future of elogind/libelogind0

Matthias Geiger werdahias at
Thu Oct 19 18:47:38 BST 2023

On 18.10.23 15:22, Mark Hindley wrote:
> 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.
Hi Mark,

thanks for looking into this. I ran into 1052064 today when I set up my 
new machine with openrc. polkit is currently uninstallable on a 
non-systemd system because of this.

I think consolekit2 might be our best bet. A possible issue might be to 
convince the poklit maintainers to re-enable the consolekit2 backend.

If it indeed gains libsystemd compatibility that'd a good replacement 
imo. Not discrediting your work or upstream here, but elogind will 
always lag behind / play catchup to the "regular" logind.

If you need help maintaining consolekit2 I'd be glad to do so.


Matthias Geiger <werdahias>
Debian Maintainer
"Freiheit ist immer Freiheit des anders Denkenden" -- Rosa Luxemburg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x18BD106B3B6C5475.asc
Type: application/pgp-keys
Size: 4036 bytes
Desc: OpenPGP public key
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the Debian-init-diversity mailing list