-
-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
have a standard set of core services for distros to use #245
Comments
Sounds like a great idea to me. We can standardise the set of base services (particularly targets) that can be relied on to be available (eg. the names you have currently for chimera as per link above) and offer your current set as an example implementation, for example. |
having some names available would be a good baseline at least, though sooner or later some things may have to rely on service-manager-related infrastructure beyond dependencies, but we'll see i guess... |
yeah, the tmpfiles issue is a good example of that. Let's see if anything else comes up. The service names is a good baseline as you say, we can start with that and build on it as necessary. |
see https://wiki.artixlinux.org/Main/Dinit and https://github.com/mohamad-supangat/dinit.d who knows will help |
i second that, rather the moving to Artix rather remove systemd in arch and have a quickest boot possible into a xinit session. |
dinit comes with a sample service set that can technically result in a bootable system, but it hardly makes full use of dinit's potential nor it provides something that would be useful as a reasonable base for all dinit-using distros to share
that means everybody is sort of doing their own thing, which means software upstreams will not be able to ship distro-independent service files like they can with systemd, which is bad for serious adoption
i've been meaning to make my dinit-chimera https://github.com/chimera-linux/dinit-chimera largely reusable, and i believe it's currently the most advanced core service set that exists for dinit; but it's downstream regardless (and currently it makes some assumptions that might not be viable for everybody, but that will change, the most notable thing right now is usage of systemd-tmpfiles but i plan to have a custom helper come with it later instead), so i wonder if we could put some effort into making a common system? not a mandatory one, but at very least something officially recommended for potential adopters, so that software has something specific to target
The text was updated successfully, but these errors were encountered: