- replies
- 0
- announces
- 0
- likes
- 1
*Ada - Np-93/237
> 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.
no gnome DE at all on artix anymore (old packages still in tree but idk for how long)
@navi gnome-session _is_ capable of loading different leaders. I explicitly made it capable of doing that
We only support systemd upstream because we don't have the expertise or capacity to QA and maintain any other configuration. But I'm happy to enable this to work downstream
I have put in every effort and quite a bit of my time to work together with people from other init systems to support this change. So I find it very disappointing to hear that suddenly we're not capable of collaboration
the post did mention we need to replace the leader process, and that's about it. this week someone in our community started to work on it, and so far had to patch gnome-session itself to do so -- looking at the code, only one path for the init worker is ever loaded. replacing the binary during packaging is not good (gentoo, artix, devuan, support multiple init systems, for example, and while i'm not involved with artix nor devuan, i am with gentoo and alpine)
i am more than happy to write a session leader and provide support for it in gnome-session, if possible (with a built-time switch), or as our own thing loaded at runtime if not, currently it is lacking of a way to properly switch the loader, unless i'm missing something in leader-main.c
imo making use of a user service manager is a good choice and i'm glad i managed to get openrc up to speed on that feature in time for projects to use it
@navi My blog post explicitly gives instructions on what needs to be done and also where to reach me if you need help. And, someone working on packaging GNOME for OpenRC did reach out to me and I did help them.
As for loading one path. You don't switch init systems at runtime, and gnome-session has no way of knowing what init system you're using at runtime anyway. But for init-system-agnostic distros you can't set it at compile time. (1/2)
@navi So the solution is one file. Whichever init system you have installed should have an associated sub-package to provide that file, and the sub-packages should conflict with each other so only one is installed at a time. This way a distro that gives init system choice can keep that behavior with one single build of gnome-session.
The OpenRC leader could have been done without a fork or any patches to gnome-session. In fact that's what I recommended should be done. (2/2)
> You don't switch init systems at runtime
openrc, s6, runit, all of those work without being init/pid1, it is possible to use any of them in combination with systemd or themselves. why would anyone do that is beyond me, but it's to note that systemd is the outlier for requiring to be pid1, not the rule -- an argument to choose the leader would be fine to do such selection at runtime -- but i guess for most gnome users, that won't really be something they'd want to do?
i don't know who the gnome packager was, nor from which distro they package for, i just know that openrc itself never got any contact
by end of week we'll have the openrc leader, and i do apologize for the original post on this thread (and for the subsequent reply as well)
