tito via Dng said on Sun, 30 Jul 2023 00:22:02 +0200

>I was looking
>really for a way to make the development of devuan viable when all
>init scripts are stripped from debian packages.

From my perspective, achieving the preceding goal is quite doable if we
view "init scripts" from a different perspective.

I suggest we form a runit script committee and a sysvinit script
committee, each of which oversees a package of **all** init scripts.
When peoplepower allows, we can also form an s6 scripts committee,
which will work hand in hand with the runit scripts committee because
s6 and runit are so similar.

I volunteer to be on the runit committee. The runit committee would
have the following functions:

* Create and test new runit run scripts for daemons.

* Assist Devuan users in creating runit run scripts for daemons not
currently in the runit run scripts package.

* Accept new run scripts from the community, test them, and include
them in the package.

* Maintain a Devuan package of runit run scripts.

Here are some benefits:

* Never again would some poor daemon upstream or package maintainer
need to burdon him/herself with init scripts, run scripts, unit files
and all that stuff. They already did us a favor by creating/packaging
the daemon: They shouldn't have the further demands of startup
scaffolding.

* This will make the development of devuan viable when all init scripts
are stripped from debian packages.

* In yet another way, we can tell Debian and the Systemd-Industrial
Complex to kiss our posteriors.

* It's possible that with our new, Devuan-specific startup scaffolding,
we can undo some of Debian's systemd requirements.

* It's possible that when we succeed with this, other sans-systemd
distros will use our system, so the systemd distros will, in a
certain way, be on the outside looking in.

About the sysvinit init script committee: Their first task, and it's
time critical, is to find and preserve every single Devuan sysvinit
init script, and put them in a package. Init scripts don't change all
that much over time, so maintaining these init scripts would be pretty
easy. What might be more difficult is creating sysvinit init scripts
for new daemons. This requires an old-timer who understood sysvinit
scripts.

A few factoids:

* Runit run scripts are so tiny that installing all of them, when you
use only a few, wastes very little disk space.

* Unlike syvinit scripts, runit run scripts are VERY easy and obvious
to create. Most are under ten lines, including the shebang. Unlike
sysvinit, they don't import swaths of shellscript functions.

* Runit can be its own init system with its own PID1, or it can serve
simply as a process supervisor for a different PID1, especially
sysvinit. This provides an easy learning curve for users and devs
alike.

* Runit has trouble running daemons that refuse to run in the
foreground. This points to the utility of a runit/sysvinit hybrid in
which daemons that refuse to run in the foreground are managed by
sysvinit's process manager, whereas all others are managed by runit.

* However, runit has kludge facilities enabling it to run
refuse-to-forground daemons directly, with a *reasonable* amount of
reliability (probably about the same reliability as sysvinit), so you
*don't have to* run a hybrid.

* Everything I've said about runit is equally true of the s6 process
supervisor and the s6 init system.

SteveT

Steve Litt
Autumn 2022 featured book: Thriving in Tough Times
http://www.troubleshooters.com/bookstore/thrive.htm