Hey, On 20/12/2022 02:52, Connor Behan wrote:
On Mon, Dec 19, 2022 at 8:01 AM Christian Hesse <list@eworm.de <mailto:list@eworm.de>> wrote:
Andreas Radke <andyrtr@archlinux.org <mailto:andyrtr@archlinux.org>> on Fri, 2022/12/16 22:46: > The older Arch developers may remember vaguely how Arch has introduced > [1] and migrated to systemd [2] becoming the new and only supported init > system. [...]
I remember these days, though I was a regular user back then. :)
The biggest argument again systemd is its complexity. Some people do prefer simple init systems with init scripts.
I agree. Wanting the most capable init system and wanting a more lightweight init system both sound like legitimate arguments.
How is OpenRC more "capable" or lightweight? Seems a bit of a strange claim, as most systemd components are optional. IIRC Alpine is looking into switching to an s6 fork as service management [1] [2]
Let's recap: Sure, systemd is complex, but it is well maintained (IMHO). Generally it works well. The benefit is that systemd units can be written quite easily, at least basic ones. Issues are easy to fix, things just work. In contrast to that the complexity comes from the init scripts with the other init systems. For each of them, again and again. Syntax errors, race conditions, what ever.
Many bugs of this type were filed in Flyspray. If we go back to having initscripts as the default (which no one is suggesting) they are sure to come back. The mere availability of another init system in the repos though will probably cause much less of a headache.
There are versions of init freedom which would be too much work as people have rightly pointed out. So let me make a concrete proposal.
1. Put openrc in [community] which I have used on my laptop for two years without issue.
Sure, but that's one test point. I can point out multiple packages which does not work on openrc.
2. Make it depend on systemd (so it is clear we are not packaging eudev) and make installation print a warning that users of netctl and devtools will need to find alternatives.
Not supporting devtools is kinda a problem as it's a big part of our distribution. Not being able to follow the official development workflow on OpenRC is kinda a big deal.
3. Put openrc-arch-services in [community] as well, 4. Bugs for these two packages will be assigned to one of the three people who've expressed interest (Andreas, TJ and myself).
Right, so we add something "unofficial" as alternative to our repositories and as it's an initsystem this is a big deal. Some software will just not work with OpenRC, for example Cockpit is hard tied to systemd. The openrc-arch-services repository lacks profiles or how they are named for most of the software in our repository. I for example am not going to add openrc support to Grafana. [3] If OpenRC is in the repositories users will expect packagers to add support, and will ask in our support channels about OpenRC. So in essence I find this whole proposal rather naive and I am a bit saddened by the FUD in this thread. If you want to run OpenRC, we have the AUR which is the perfect place for something unsupported in my opinion. You might run into issues getting support from our support staff then however. [1] https://skarnet.com/projects/service-manager.html [2] https://ariadne.space/2021/03/25/lets-build-a-new-service-manager-for-alpine... [3] https://gitweb.gentoo.org/repo/gentoo.git/tree/www-apps/grafana-bin/files/gr...