On Sat, 06 Jul 2019 08:49:52 +0200
Martin Steigerwald <martin@???> wrote:

> Steve Litt - 06.07.19, 07:24:
> > > It is not
> > > difficult to think of the day when Debian will remove completely
> > > sysvinit script in all packages.
> >
> > Pre-Cisely!
>
> I would not bet on that.

Depends on the odds. Obviously nobody without a time machine or crystal
ball knows for sure. You prioritize the existence and activities of the
debian-init-diversity group. I prioritize the profit motive of
complexifying GNU/Linux, as well as some former bad acts of the Debian
project being a pattern for their future activity.

>
> There is the debian-init-diversity group where Debian and Devuan
> people work together. Back then I helped to bring that forward and
> there is still a lot of activity.

Thank you for that. Regardless of the final outcome, you did something
important in undoing the savage mistakes of late 2014. A lot of people
talk: You did something, and the something you did might benefit all of
us.

> Developers in that group did
> updates for sysvinit, insserv, startpar, openrc, runit and others for
> Debian which then could be and have been used in Devuan. At the same
> time there is a new upstream maintainer for sysvinit, insserv and
> startpar so these are all actively developed. These developers closed
> a ton of sysvinit related bug reports in Debian. It's amazing. In
> fact the upstream developer even dug through Debian bug tracker to
> find bugs to fix.

[snip sysvinit, insserv and startpar bug fixes]

My feeling that sysvinit is not in safe hands in the Debian project
isn't based on the quality of sysvinit or its components. As a matter
of fact, I never noticed any bugs or weird stuff with sysvinit during
the 13 years I used sysvinit as my daily driver init (with occasional
forays into upstart and daemontools). My feeling is based on:

1) Corporate profit motive for keeping systemd the only init in town.

2) The (insert your own noun epithet) of "FreeDesktop.Org".

3) Systemd's technological ability to sabotage all attempts at
alt-initting a computer.

4) The huge moving-target workload necessary because of #3.

5) See the response to your next statement...

> While Debian project for now will keep the libsystemd0 dependency on
> a lot of packages

Which makes libsystemd0 the ideal kill switch for init diversity. One
might ask who would be so mean as to kill init diversity within Debian?
For a list of such people, see the original decision:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708

> that not absolutely need it and regarding init
> diversity there is a place for Devuan to go further, there are Debian
> developers who strongly prefer to use sysvinit and who prefer to
> avoid Systemd.

It's completely understandable that some people like sysvinit.

[snip highly successful case history of migration to Devuan with
sysvinit]

> That kind of inspired the user-services project I did not work on
> after that again. I more and more believe it would be good to package
> that stuff in a way that it would work out of the box for users. Or…
> well to do some post package processing to make it work.

For a distro like Debian or Devuan, "works out of the box for users" is
almost a necessity, in the long run. When I recommend a series of steps
to accomplish something, it's for the early adopters.

> Of course it is likely at some time some may bring up that topic and
> there would be a discussion, but… assuming from the past, that
> discussion would take a time to come to an conclusion. So I believe
> the risk that all Debian developers would *suddenly* drop init
> scripts from packages is quite low. There would be at least a
> considerable forewarning time.
>
> That said, I agree it would be good to find a way to inject runit
> symlinks into packages, cause I believe it to be unlikely that many
> Debian package maintainers would include runit support.

Pre-cisely! Runit /etc/sv directories and any symlink strategy can be
implemented by people who care about runit. Same for s6, OpenRC, Epoch,
etc. I don't think developers of daemons ever should have been tasked
with making scripts or unit files for *any* init.

> However that
> said, I would.
>
> So: If you like to provide runit support for fio Debian package,
> please go ahead. As long as the runit support is implemented in a way
> that the existing start support for sysvinit – which I implemented
> back then – and systemd still works as well, and you tested the runit
> support, I gladly accept a merge request. I'd even make some effort
> to put it into the package itself, in case you provide something to
> me, in case you are not familiar with forking a git repo and
> providing a merge request.

I can't think of anything I or anyone could do, regarding runit
runscripts, that would adversely affect sysvinit. As far as systemd,
runit and s6 are never going to use the systemd mechanism by which
service A tells systemd that it's loaded, but if someone switched back
to systemd, that mechanism will still be there.

> But also it would be good to have something like this to fix up
> Pulseaudio and Evolution for Devuan users.

:-) That's not an itch I want to scratch, someone else can do that.


> So I believe it is good to let go of any drama and fear and just get
> on with actually doing something to improve runit / s6 support.

Well, if I were to help integrate runit and s6 into Devuan either
directly or through Debian, would it really matter if my incentive
included drama and fear?

SteveT

Steve Litt 
July 2019 featured book: Troubleshooting Techniques
     of the Successful Technologist
http://www.troubleshooters.com/techniques