Hey,
On 20/12/2022 02:52, Connor Behan wrote:
On Mon, Dec 19, 2022 at 8:01 AM Christian Hesse <l...@eworm.de
<mailto:l...@eworm.de>> wrote:
Andreas Radke <andy...@archlinux.org <mailto:andy...@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/grafana.initd
