The future of elogind/libelogind0
Matthias Geiger
werdahias at riseup.net
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.
best,
--
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: <http://www.chiark.greenend.org.uk/pipermail/debian-init-diversity/attachments/20231019/74a710c8/attachment.asc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://www.chiark.greenend.org.uk/pipermail/debian-init-diversity/attachments/20231019/74a710c8/attachment.sig>
More information about the Debian-init-diversity
mailing list