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

On Mon, 2025-10-20 at 15:01 -0500, Douglas R. Reno wrote:
> 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.

Replying to the original mail, but I've read the answers (hopefully
I've received all of them). First, about options:
- we have already gone the '1' route when the "localed" service daemon
became required for non English locales in GNOME. But the daemon had
already been written for Gentoo, and taking the maintenance, I heavily
modified it (to adapt it to newer GLIB API, fix a few bugs, and make it
work with SysV). This was a 2-month work (well, with one month just to
learn GLIB API), but now maintenance is lightweight. I think I could
write that user service daemon, but with no commitment on the delay
(sorry for not being more dedicated).
- Option '2' is just endeavoring into a more and more difficult and
time consuming process. Unless *LFS has a way to gather a big community
around it, I think it will become unbearable at some point in the
future.
- Concerning option '3', I don't see the benefit of going to another
init system. SysV is good for education purpose, systemd is a de facto
standard, anything else is in between... But I'd like to elaborate on
Zeckma's suggestion: systemd, as of now and I guess for some time, will
only be needed for DE's and DM's. I don't see the point of trying to be
educational up to such a complex thing as GNOME or KDE. So we could
just remove them from the SysV book (this would leave Xfce, and I am
not sure about LXQt), remove also some DM from the SysV book (keeping
lightDM at least). The SysV book would then still be a complete book,
but we would remove a lot of maintenance burden. And if some user wants
to have say, GNOME on SysV, then he would be on his/her own (*LFS
archives could still be used for this purpose)

Note that I am a SysV and GNOME user ATM, and I dislike systemd. But
long ago in my life I was forced to move from an operating system named
VAX/VMS to Unix (SUNOs actually), and of course I was thinking VAX/VMS
was superior. Well, in retrospect, I could do the same things with
both, and I haven't missed some unique features of VMS for long...

Pierre

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