On Sat, 29 Jul 2023 19:26:02 -0400
Steve Litt <slitt@???> wrote:

> 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.

Hi,
if the participants to devuan online meetings have to be taken into
account it seems to me there are more committees than developers.

> 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.

I don't know exactly how much daemons are in the debian archives
but this looks like a full time job.

> 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.

I still think that a debian policy to actively hand over the runit,init,openrc
scripts if removed to orphan-* packages is the easier alternative
and probably could be setup as debian still states that it supports
init diversity. What do the people that is/was in debian about
this proposal?

> * 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.

This will never happen as the human and economic
resources are infinite but devuan's are not.

> * 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.

Would be nice but has to be proven yet.

> 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.

Seems you do strongly prefer runit....

> SteveT
>
> Steve Litt
> Autumn 2022 featured book: Thriving in Tough Times
> http://www.troubleshooters.com/bookstore/thrive.htm
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Ciao,
Tito