Hi Alex,

Axel Beckert <a...@debian.org>
> Thomas Goirand wrote:
> > 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.

> The last time I looked (years ago), there were features in sysvinit
> which weren't in OpenRC (yet). IIRC not having concurrent execution of
> boot scripts was one of the missing features and the reason for e.g.
> our derivative distribution GRML to not switch to OpenRC some years
> ago.

OpenRC does have parallel execution of scripts, it works well, but when
activated, the display output is still a bit ugly. I'm not sure why (I
haven't investigated). If the issue is just the screen output, then
probably it can be worked on.

> Yes, the fact that these runscripts use the same paths as classic
> initscripts in Debian is a pity.

Well, yes and no. If we are to keep standard shell script forever,
indeed, that's a pity. If we instead decide that it's time to move on,
and standardize with runscripts instead, then it's very nice that OpenRC
reuse the existing shell script, and allow us to slowly replace them.

The pity is to currently have to maintain runscripts *AND* shell
scripts, instead of simply deprecating these boring init scripts.

> I'd really prefer to continue to have both init systems in parallel
> (as long as they're maintained upstream), with different paths so that
> both can be used properly.

This is exactly what I think should not happen. If we give package
maintainers the chance to get rid of these ugly init scritps and replace
them by superior runscripts, then probably they will look at systemd
alternative differently, and agree to maintain/write runscripts, for
example to support non-linux ports.

If instead, we keep having old style shell script, which OpenRC also
support, I bet copper against gold that mostly everyone wont even bother
writing/maintaining runscripts, and keep pestering about init shell scripts.

> I'm though not really sure how much impact
> it will have to have different paths for the runscripts than upstream.

Writing a small patch to have OpenRC prefer a runscript with same name
in a different folder over a shell in /etc/init.d shouldn't be very
hard, but that's really not what I wish to happen. I really would like a
way so that we get rid of the old shell scripts for something more
modern and declarative.

> Maybe packages can ship them somewhere else than default, and openrc
> uses dpkg-divert to get them into the expected path if and only if
> openrc is installed.

Files in /etc/init.d are CONFFILE files. I don't think dpkg-divert works
with CONFFILE files (does it?). Even if it did work, we cannot have
OpenRC reimplement all of the init scripts of Debian, these must be
carried in each packages.

> P.S.: One of the really cool things about Buster is that it offers 5
> or 6 different init systems! Now that's what I call diversity.

How many of them have good support in every package?

Benda Xu <hero...@gentoo.org> wrote:
> 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?

Thorsten Glaser <t.gla...@tarent.de>
> 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...

Cheers,

Thomas Goirand (zigo)

Reply via email to