i wonder what i could do, if anything at all, to get better openrc support on base debian and base arch
@navi oooh, if you're willing to dip into Debian-land, I'll be following you š
@ska @navi contact the debian-init-diversity mailing list (or #debian-init on OFTC); there are people favouring openrc and/or s6 there as well
(tbh I have never had any interest in alternative inits myself, I even donāt really like sysvinit, I just use it on Debian because itās proven and I know where the downsides are)
@mirabilos @ska @navi 1/ running it as daily driver. The main problem is that you're kinda forced to run elogind, and that user services should be tested / integrated more. I do not have any energy to get user services e.g. for pipewire upstreamed. There's also the issue that some packages ship sysvinit scripts, and you have to use those over the a shorter, concise openRC one. I think diversions could fix that,
@mirabilos @navi @ska /2
might need to talk to a fellow DD about it.
I also want to create a minimal installation script with mmdebstrap, so I don't need to manually purge systemd and reinstall openRC.
might need to talk to a fellow DD about it.
I also want to create a minimal installation script with mmdebstrap, so I don't need to manually purge systemd and reinstall openRC.
@werdahias @ska @mirabilos
next release will support installing scripts to /usr/libexec/rc and /etc/rc so that could also be a way to avoid sysvinit
but really why is debian still shipping sysvinit scripts i thought it had went all in on systemd
next release will support installing scripts to /usr/libexec/rc and /etc/rc so that could also be a way to avoid sysvinit
but really why is debian still shipping sysvinit scripts i thought it had went all in on systemd
@mirabilos @navi @ska
Unfortunately most heavily favour systemd, and even a (hidden) option in the installer is likely not happening.
Unfortunately most heavily favour systemd, and even a (hidden) option in the installer is likely not happening.
@ska i am going mostly because i'm seeing a lot of people unhappy with systemd who also can't really use alpine or gentoo
having you come along would be nice i think, getting both openrc and s6 properly setup
having you come along would be nice i think, getting both openrc and s6 properly setup
@navi @ska @mirabilos well, some maintainers even dropped them without any comment, thus breaking things. Will openRC then prefer the ones in /etc/rc? Then I can start rewriting all of them.
@werdahias @ska @mirabilos
currently iirc /etc/init.d is still first but i'm pretty sure we can change that, and that'd be for the best
currently iirc /etc/init.d is still first but i'm pretty sure we can change that, and that'd be for the best
@navi @ska @mirabilos great :) I honestly believe openRC + seatd is the future. udev is ok, but the rest of the systemd operating system can die for all I care.
- replies
- 1
- announces
- 0
- likes
- 1
@werdahias @navi @ska long as it doesnāt break the current sysvinit setupā¦
@mirabilos @navi @ska I wouldn't think so. A major issue would be getting those scripts upstreamed and then shipped in Debian
@navi I'm thinking that we could work on the common declarative format first, then write sysvinit and systemd backends as well, so we could arrive with a migration plan already shrink-wrapped.
If things go well I may be funded to do the declarative format this summer.
@ska we really should start looking into it
i am a bit worried about the declarative format being way too limited by only being able to express the common subset of all service managers, and end up missing on stronger points of each individual one
but maybe we can design something that works well given the limitation
i am a bit worried about the declarative format being way too limited by only being able to express the common subset of all service managers, and end up missing on stronger points of each individual one
but maybe we can design something that works well given the limitation
@navi @ska Well maybe something that works in a simple manner for 90% of daemons would be fine, heavier lifting then being done for more complex cases or greater integration.
That said depends on goals but could be a way to make switching to new service managers easier, so like a distro doesn't suddenly needs to write thousands of scripts / figure a lengthy migration method.
That said depends on goals but could be a way to make switching to new service managers easier, so like a distro doesn't suddenly needs to write thousands of scripts / figure a lengthy migration method.
@navi @werdahias @ska @mirabilos i run sysvinit on debian sid (not devuan)
it's annoying to rip systemd out but feasible
the resolution was to prioritize systemd but not remove other inits iirc (paraphrasing)
it's annoying to rip systemd out but feasible
the resolution was to prioritize systemd but not remove other inits iirc (paraphrasing)
@werdahias correction because i just checked, the code on master currently goes
/etc/rc/init.d
/etc/init.d
/usr/local/etc/rc/init.d
/usr/local/etc/init.d
/usr/libexec/rc/init.d
meaning /etc/rc goes first, but the sysvinit ones would still go above the ones in the /usr tree (a lot of distros want to ship init scripts to /usr, so)
@navi currently sysvinit scripts in Debian are shipped in /etc/init.d so if /etc/rc has a higher priority then this is great since "pure" openRC scripts can be used over sysvinit ones.
@werdahias it does have a higher priority
moving init script to /usr *one day* would be good... i wonder if eventually we could have a build-time opt to disable /etc/init.d as a whole
moving init script to /usr *one day* would be good... i wonder if eventually we could have a build-time opt to disable /etc/init.d as a whole
@navi my concern is mostly having a place for native init scripts they can live in while not conflicting with the sysvinit ones. In Debian a package must not ship the same file under the same path.
@werdahias yeah, i'd like the distribution provided init script to go in $libexec
but that would mean the sysvinit ones would take priority, so we can't, and instead have to ship them in /etc/rc
but if we could one day remove /etc/init.d from the default search path, then libexec/rc is usable again
but that would mean the sysvinit ones would take priority, so we can't, and instead have to ship them in /etc/rc
but if we could one day remove /etc/init.d from the default search path, then libexec/rc is usable again
@navi right. Well, once this change lands, I hope I can dedicate some time to write native init services for openRC for a minimal install (cron, ssh, boot stuff,...)