The future of elogind/libelogind0

[Mark Hindley]

On Wed, Oct 18, 2023 at 02:22:26PM +0100, 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.

I have just uploaded version 252.9-1debian1 to experimental. I have added a
preliminary patch which enables elogind to use libsystemd0 compatible cgroups
and dispense with libelogind0. It works for me, after a reboot, but I would
appreciate wider testing and comments.

Some services will need restarting after libelogind0 is removed and users will
need to log out and back in. I have handled polkitd in the postinst, but others
may be required.

I know there has been some recent activity upstream, but that only wrt 253 which
is still insufficient to address the binary compatibility. And I believe systemd
255 will be uploaded to sid soon.

If this approach works for others, I think it will be better as it will decouple
us from the requirement to constantly play catchup with systemd.

Thoughts and comments?

Best wishes

Mark