Bug#946197: Let's switch to OpenRC?

[Jesse Smith]

>>>> OpenRC is actively maintained upstream,
>> 
>> Sysvinit is AFAIK maintained upstream again since a year ago or so.
>> So this is no reason to get rid of sysvinit. Note all the new
>> upstream releases, Dmitry has uploaded in the past year: 
>> https://packages.qa.debian.org/s/sysvinit.html

> I never wrote that sysv-rc isn't maintained, that's not the point I'm
> trying to make.


Just to clarify this point, SysV init has been actively maintained
for about two years now. Hi, I'm the upstream maintainer.


>> I think it would be time when OpenRC has a systemd .ini parser, to 
>> also make use of systemd units.

> Do you think this could be written?

This is something we've been looking at in SysV init. We have a script
than translates systemd unit files to shell scripts. However, we don't
have a service manager that parses them on the fly finished yet. We can
go through dependencies and perform simple actions, but there is a ways
to go yet. OpenRC would be welcome to borrow our code for this.


>> Dropping sysvinit as it works and as admins know... no. Absolutely
>> NOT.

> Thorsten, do you have any point of argumentation besides "it works and
> we know it"? That's IMO a bit light...

Why is that not a strong reason for keeping it? "If it's not broke,
don't fix it," is a pretty solid argument.

Apart from that, SysV init is small, light, well known code with few
bugs and a fairly static/conservative development model, which is
something I personally really like to have in core components, like init.

To be clear, I like OpenRC. It's a great init/service manager, and I'm
all for supporting it. But to replace an old technology it should be
demonstrated that the newer technology is better, not just newer.
Otherwise you're risking introducing new problems and alienating admins
in the process.