Some of you have probably seen the blog post a few months ago about how GNOME is more strongly depending on systemd. The changes mentioned there have landed into the latest stable versions of the mentioned software (GNOME 49) and do affect us. In particular, the main culprit is the removal of the non-systemd fallback code in gnome-session. This makes it currently impossible to launch gnome-shell/mutter on a non-systemd system. A fairly straightforward patch of using elogind, like what was previously done, no longer works either.
Since we don’t have the time or interest to write a new non-systemd codepath for gnome-session, this means that all support for gnome-based desktops has to be dropped. In particular, the affected packages would be gnome-session, gnome-shell, mutter, and gnome-settings-daemon. For now, the old versions are still in the repos but because there is so much intertwining between other gtk/gnome packages, there is no guarantee they actually work and will later be removed from our repos.
Standalone gnome applications will still continue to be packaged, but it is simply not feasible anymore to support gnome desktops without systemd.
You must log in or # to comment.
I read as “Arch Linux drops support for GNOME” and my heart fluttered
I did the same but was skeptical since Arch is an only systemd system so there’s no point it would affect Arch anyways
I did the same even though I had seen this headline before
Hopefully other software doesn’t follow this path, otherwise it will be practically impossible to run a distro without systemd.
It will keep coming.
For GNOME, I think Chimera Linux is working in something with Turnstile that non-Systemd distros can use to get it working again.
So no GNOME on BSD anymore?
If you want GNOME you need a corporate aligned linux-only desktop with all the IBM trimmings? IBM who has been known forever for the poor quality of their code? IBM who pays by the KLOC?
Linux itself is entirely “corporate-aligned.” It exists and is developed almost entirely by and for corporations.
Dang, i knew this was gonna be problematic, but i thought it might’ve been fixable with an elogind type of approach. I don’t use gnome myself, but it definitely sucks if you’re someone who likes using gnome but doesn’t want to use systemd. I’m a Void user myself, so i’m interested in seeing if the Void team ends up making the same decision as Artix.
I feel like Void devs will first wait it out. Perhaps Chimera Linux’ devs will come up with some workaround by then. A possible workaround could be to make Duncaen’s systemd fork official. Though I’m not sure if maintaining 2 init systems would be less work than to patch the systemd API specific stuff.
The prob here?
I dug up this link from June, which tells us why they made such a design choice of strong depressing on systemd.
https://blogs.gnome.org/adrianvovk/2025/06/10/gnome-systemd-dependencies/
Funny thing is every open source developer strives to support as many systems and platforms as possible, by following best practices and open standards, GNOME goes backwards.
“Some of you have probably seen the blog post a few months ago about how GNOME is more strongly depending on systemd.”
“Standalone gnome applications will still continue to be packaged, but it is simply not feasible anymore to support gnome desktops without systemd.”
What I always say when anyone tries to defend systemd but I just get shut down and talked down to because nobody wants to admit systemd lead person is on purpose influencing with flawed and unethical objectives/workflows that undermine actual openness and community efforts. He don’t give af about the community.
This isn’t a secret plot by systemd, this is gnome making dependency choices and a distro that explicitly doesn’t support the new dependency being left in the cold. That’s just how dependencies work.
Boo systemd. Boo I say. Boo
