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

On 10/20/25 14:01, "Douglas R. Reno" ([email protected] via
blfs-dev Mailing List) wrote:
 > ...
 > 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.

A little warning here in the beginning that this email contains a
suggestion that may be controversial, but that'll come in about the
later half of the email.

Option 1 seems to be DE specific, so the same work will need to be done
for every DE that follows in GNOME's footsteps. Long term, it doesn't
seem worth it, but we don't know how spaced out each instance will be.

Option 2 is a definite no-go due to maintainence burden and, for a
large part, will have us rely on another's work which may take weeks
to catch up each GNOME or other DE update.

Option 3, like with option 2, suffers from the same problem in that we
will still have to rely on other's work and hope they catch up in a
timely fashion for their specific implementation replacing what Systemd
can do.

Above all the options, I think option 3 will lead to the most support
and be the safest net we can fall into despite possibly leading to less
educational material that is generated from an archaic init system like
Sysvinit.

Now comes in my suggestion that may be controversial, which is to scrap
the Sysvinit version of the *LFS books, leading to only one version of
each book, disregarding forks and branches of each book. This has
advantages of its own, but focusing on the matter at hand, this results
in:
1. We would have the maximum support that we can get.
2. We don't really have to wait for third parties to develop solutions
    to catch up, and we could update whenever we wish, in a perfect
    world.
3. Reduces maintainence burden in different ways. We'd no longer have
    to have two sets of instructions for various packages. Every
    editor would be using the same init system and thus encounters
    and fixes the same issues that result from that init system, instead
    of having dedicated editors for specific init systems. We wouldn't
    need to think about any of these issues with packages going
    Systemd-only as we ourselves would be Systemd-only.

There are multiple reasons to not use Systemd, they've been discussed
multiple times. For us, a big reason to have Sysvinit is for education
purposes. But we have to land in the middle, to have both education and
not have something that leads to breaking our backs.

If we ever do go this route, we still need to give users a sense of
options. We can explain init systems, their differences, how users can
go about deviating from the book, and point to examples, including an
version of the book that was the last one that included Sysvinit,
perhaps some tips as well like not forgetting to delete
/usr/lib/systemd every now and then.

Focusing on GNOME again, there was an issue with GPUs, and Sysvinit.
This led to several hours being used up to debug and fix this. It uses
up a lot of hours and tires out editors. With Systemd, the intended
init system target, didn't have the issue. Several issues of its ilk
will prop up in the future if we don't cut out Sysvinit.

So what it really boils down to is reduce waiting and saving burden
of maintaining the books and systems with LFS on them for editors.

I understand that this suggestion will probably be thrown out but
wanted to give my two cents regardless because I believe this is the
best route.

- Zeckma

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