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

"Immediately drop Gnome or suspend support for it. Enough is enough, I
think. Use freed up ressources for better purposes."

GNOME is one of the most used if not the most used DE on Linux, so getting
rid of it would be detrimental to the overall project. There are also
plenty of other packages that depend on its various programs and libraries,
so those will have to be removed as well.

I for one would actually prefer to actually work around the issue then to
just scrap the whole thing, so options 1 and 3 are already more than
suitable outcomes on how to resolve this.

Il Mar 21 Ott 2025, 14:21 Rainer Fiebig <[email protected]>
ha scritto:

> 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

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