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

> Martin Steigerwald said on Sat, 29 Jul 2023 10:10:11 +0200
>
> >Steve Litt - 29.07.23, 08:50:48 CEST:
> >> This isn't much of a problem, because runit and s6 run scripts are
> >> trivial to make, and there's documentation for a lot of them.
> >>
> >> And don't forget, you can use sysvinit as PID1, and then from
> >> /etc/inittab run runit or s6 to do the actual daemon startup work.
> >
> >There is the package runit-services which contains quite some of them
> >already.
>
> And if you can't find the run script you want in the package, see
> http://smarden.org/runit/runscripts.html .
>
> If you want to use sysvinit as PID1 but use runit to handle all your
> daemons, see http://smarden.org/runit/useinit.html#sysv . This is an
> excellent option because you can cut services over one by one. Also,
> runit doesn't work well with those few daemons that cannot run in the
> foreground, so you can use sysvinit init scripts for those few.
>
> For process dependencies, see
> http://smarden.org/runit/dependencies.html and
> http://smarden.org/pape/djb/daemontools/noinit.html .
>
> SteveT
>
> Steve Litt
> Autumn 2022 featured book: Thriving in Tough Times
> http://www.troubleshooters.com/bookstore/thrive.htm
>

Hi,
Thanks, for the docs will take a look at them , but I was looking really for a way
to make the development of devuan viable when all init scripts
are stripped from debian packages.

Solutions so far:
1) a service file to init script translator,  onefang thinks it is doable
     I think it is rather problematic, full of corner cases, hardcoded
      stuff and not KISS at all.

2) One more solution I could think about would be to ask debian
    package maintainers to actively move init scripts to orphan-init-scripts
    package and I suspect they would be delighted.
    Maybe a policy about this could be created? retroactive to all scripts 
    dropped between the last two (three?) releases?
    What do the long time debian insiders think about that?

3) last solution would be to develop a devuan in house KISS init system,
    but this is like opening a can of worms because I don't think devuan developers
    could easily agree about a standard and probably lack the manpower to do it

4) maybe the next beer brings even more brilliant ideas.....


Ciao,
Tito