GNOME 49 and SysV systems (possibly affecting other DEs in the future too)

Good afternoon folks,

I wanted to provide an update on GNOME 49. It won't be quick though, and 
I know this is a lot of text, but please hang in there as I need some 
feedback.

There are two problems that are afflicting GNOME 49 on SysV. The first 
is that we don't have a user services implementation, only a system 
services one. This puts us in a bit of a bad position, as all 
non-systemd based distributions other than Slackware have this 
capability. Most of them at this point are using Gentoo's OpenRC, which 
is a dependency-based init system similar to SysV that has integrated 
support for user sessions (with the definition here being services that 
are intended only for the user which is currently running as part of 
their session, e.g. pipewire, kwallet/gnome-keyring, 
gnome-settings-daemon, etc.) - other than OpenRC-based distros there is 
also GUIX which is running GNU Shepherd.

The lack of a user services implementation is going to start causing us 
more problems at some point down the road as well, so it won't entirely 
just be GNOME specific. GNOME 49 dropped the non-systemd fallback 
functionality for gnome-session, and gnome-session now needs to be able 
to launch services such as Localsearch, gnome-settings-daemon, and 
others. One of Gentoo's developers is implementing this with 
https://github.com/swagtoy/gnome-session-openrc  - and a maintainer of 
GUIX has implemented this with 
https://gitlab.gnome.org/noe/gnome-session-shepherd

There is a very good chance that other desktop environments and programs 
will start to use user services more in the future. We're already having 
to work around this with Pipewire and Wireplumber, though in that case 
we got around it on SysV with using XDG Autostart files. I've heard 
rumblings that Plasma may transition to having more of a systemd-focused 
initialization procedure, and distros like Void Linux, Gentoo, Alpine, 
and a few others use OpenRC or another init system that can be adapted 
to use user services. We don't want to get caught in the crossfire as 
the rest of the world moves towards user services, and currently we're 
the only group that I've been able to find that explicitly uses sysvinit 
instead of an alternative init system such as OpenRC (and of course 
systemd for the systemd users).

One knee-jerk reaction to this would be to drop GNOME. I don't entirely 
think GNOME is the problem here, they communicated this well in advance 
via blog posts and pull requests, and eventually other desktop 
environments including Plasma will likely be affected as well. We have a 
sizable enough group of people who use GNOME that it doesn't make sense 
for me to advocate dropping it for SysV either. As far as I'm concerned, 
that's off the table.

Note that this is entirely separate from the systemd-userdb problem for 
GDM as this affects starting GNOME whatsoever. A ticket was filed with 
elogind to try and get proper support for systemd-userdb at 
https://github.com/elogind/elogind/issues/323 - and this is also 
separate from X11 being disabled by default (and Wayland sessions do 
like user services...)

At this point though I feel the need to make a decision and receive some 
feedback. There are a few approaches I can go with this (and I think 
dropping GNOME isn't the best way here, eventually again other DEs will 
have the same problem):

1 - Implement a user services daemon for Sysvinit. This will be a 
complex endeavor, but is one way. I could potentially do it with a bash 
script or a C program, but I'll have to find a way to get it to tie into 
the general system. I could use the gnome-session-openrc project to get 
this going with gnome-session in theory, but it would be challenging and 
I would need to figure out the right way to architect it. I would also 
need to add in bootscripts (or in this case really, "userscripts") to 
replace the systemd user units that GNOME and other DEs and applications 
use, augment leader-main.c in gnome-session to work with our "service 
manager", and also modify gnome-session-ctl to do the same. This info 
comes from 
https://discourse.gnome.org/t/accompanying-non-systemd-distros-to-replace-gnome-s-new-dependencies-on-systemd/29411/2.

2 - We could go the route of Slackware's 3rd party repositories and 
carry a 19k+ line patch to remove the dependencies on systemd and 
restore the non-systemd fallback session to gnome-session. The problem 
with this is that it's not only not sanctioned by upstream, but will 
carry an even larger maintenance burden. In any case this is definitely 
not the way I want to go.

3 - We could move LFS to another non-systemd init system, such as 
OpenRC. This is also a huge project that I could do, but would have more 
support by different upstreams and other distros that we could 
reference. This also solves the user session problem and we could adopt 
gnome-session-openrc to make our lives easier there.

Which option is the best here? Does anyone else have some ideas? Either 
way I will need to implement something similar to 
gnome-session-openrc/gnome-session-shepherd if I need to implement a 
user services daemon for sysvinit, but at this point I need to have some 
feedback to help me make a decision before I continue.

- Doug

-- 
http://lists.linuxfromscratch.org/sympa/info/blfs-dev
Unsubscribe: See the above information page