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

On Mon, Oct 20, 2025 at 1:57 PM Zeckma
<[email protected]> wrote:
>
> 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.
>

I also believe that 1 or 3 is the best option but I side with Bruce on
the only SystemD topic. The sysv books provide an actual look into
what the system's init is doing which is invaluable for educating the
user on how a Linux system works. OpenRC or runit would probably be my
pick for a new init system but I definitely see where you're coming
from on the scrapping angle.

Maybe a middle ground could be only supporting systemd on BLFS but
even then seeing how the different run-levels interact and escalate
with one another (in systemd's case the target system) allows you to
go beyond a basic 101 of how the init system works. I personally
believe that *LFS's ability to go beyond a basic system and get
something that's actually usable day-to-day that I fully understand is
what makes it such a valuable resource (even though I now use SystemD
I used to only use Sysv).


-- 
Rahul

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