Dear sysvinit maintainers,

OpenRC is actively maintained upstream, and is a full replacement of sysv-rc,
including many improvements.

Currently, packages are stuck with long, non-declarative sysv-rc scripts, and
cannot switch to superior runscripts, interpreted by /sbin/openrc-run, which
enable declarative-only scripts.

So, my proposal is to get rid of sysv-rc provided by sysvinit, in the favor of
OpenRC, so that developers can start replacing their init scripts by superior
runscripts.

Note that this doesn't mean we completely get rid of the sysvinit source
package, as we still need a large chunk of it, like for example the PID 1 in
OpenRC can continue to be sysvinit. We also probably need other components,
like for example bootlogd, sysvinit-utils, and maybe others.

I'm opening this discussion in the BTS, as I would like to see what the opinion
of sysvinit maintainers is.

I'm also unsure what would be technically needed to get sysv-rc automatically
be replaced by OpenRC. Maybe we could make sysv-rc become a metapackage that
depends on OpenRC?

Your thoughts?

Cheers,

Thomas Goirand (zigo)

Hi,

Thomas Goirand wrote:

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

Is that now the case?

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.

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

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. I'm though not really sure how much impact
it will have to have different paths for the runscripts than upstream.

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.

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.

		Regards, Axel

Hi Thomas,

Thomas Goirand <zigo@debian.org> writes:

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

Yours,
Benda

Hi Thomas,

Thomas Goirand <zigo@debian.org> writes:

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

Yours,
Benda

No.

Supporting it as an alternative, granted, not even worth discussing.

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

bye,
//mirabilos

Hi Alex,

Axel Beckert <abe@debian.org>

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

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.

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.

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.

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.

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.

How many of them have good support in every package?

Benda Xu <heroxbd@gentoo.org> wrote:

Do you think this could be written?

Thorsten Glaser <t.glaser@tarent.de>

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)

Hi Thomas,

Thomas Goirand wrote:

I think it does kinda work for most cases, but it is IIRC neither
supported nor recommended. Thanks for reminding me of that point!

I would expect a fallback as systemd does. Init-scripts are the lowest
common denominator as they can be used as fallback for at least the
three best-known init systems in Buster. (I have no experience with
runit, s6, pid1, tini, dumb-init and maybe the one or two other
(container?) init systems of which I forgot the name.)

None anymore. The only one which ever had that was sysvinit.

P.S.: Anyone ever has taken metainit into account in this discussion?
I must admit, I just stumbled upon it.

		Regards, Axel

I don’t want to learn a new init system. If I couldn’t have sysvinit
I’d likely go with systemd for knowledge reusability, even though it’s
a fat, intrusive, pile of things.

I’m a BSD person, I never even liked sysvinit and sysv-rc (I ran file-rc
for a while but it was not good eiter). I keep it, though, because it’s
proven, well-known, low-overhead technology.

So, by all means, add OpenRC support, but absolutely not at the cost of
something we can currently have. If it’s not possible to have both, I’ll
fight tooth and nails against OpenRC.

bye,
//mirabilos

Hi Thomas,

Thomas Goirand <zigo@debian.org> writes:

The ugly output is caused by
/lib/lsb/init-functions.d/20-left-info-blocks from lsb-base.

Thomas Goirand <zigo@debian.org> writes:

I think so.  It's on my agenda.  Anyone is welcomed is she wants to
join.

Yours,
Benda

I don't have such file in my system. Has it moved somewhere else?

This feels like an exciting feature. I wouldn't know where to start, but
by all means, if I can help, let me know.

Cheers,

Thomas Goirand (zigo)

favor of
superior
runscript (with
runscript I mean the native runit init scripts).
Also as a side note, I suspect you are a bit underestimating the work
needed to replace like ~1000
working scripts into their respective Debian packages.

Regards,
Lorenzo

control: tags -1 +wontfix

[2019-12-05 10:32] Thomas Goirand <zigo@debian.org>

Personally, I like openrc more that sysv-rc, but as was already pointed,
sysv-rc already here and works, while pushing support for another init
system into ~1300 packages is hard.

And if current General Resolution will favor systemd-only vision of
Debian future, then it will become plainly impossible.

Tagging as wontfix.