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

Am 20.10.25 um 22:01 schrieb "Douglas R. Reno"
([email protected] via blfs-dev Mailing List):
> 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
Oh well, yet another depressing development.  Anyway - I'd go on the
offense instead of just passively adapting to negative developments.
So, as an immediate reaction, here's a rough sketch of what would be my
action plan:

- Immediately drop Gnome or suspend support for it.  Enough is enough, I
think.  Use freed up ressources for better purposes.
- Make that decision and the reasons for it *very* public.  Threaten to
do so with any other DE/DM that precludes or obstructs support for
alternatives to monoplistic systemd.  Cause a stir in the Linux-world.
- Side with / seek support from any entity that supports digital freedom
and digital self-determination.
- Prepare for the worst with solution "1".

I have one request: should you really decide to drop SysV, please let
users know well in advance so that they have enough time to seek out
alternatives.  Thanks.

Rainer

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