On Fri, 12 Aug 2016 11:32:41 +0200
Fred DC <adei@???> wrote:

> Hi,
>
> My apololgies for sounding a bit emotional about this issue.

The behavior of the poetterists is enough to make anybody indignant.

>
> If, up to now, you have "runit" running as pid 1 and managed to
> maintain the ability to boot from the kernel commandline using
> the sysv-init read on.

I don't understand. Do you perhaps mean that sysvinit is PID1, and you
use runit strictly as a process supervisor? The reason I ask this is,
whatever acts as PID1 is what boots the kernel.

>
> The latest update to package 'runit' *wipes* out the 2 binaries
> /sbin/runit-init and /sbin/runit, in other words, the carpet has been
> pulled from under the init.

My understanding is that /sbin/runit-init is Runit's PID1 executable,
and /sbin/runit is Runit's early boot manager and process supervisor.
It would seem to me that, together, they comprise the entirety of
runit's capabilities (unless one cobbles something together with runsv
and runsvdir, etc). So if they took away these two executables (rather
than placing them somewhere else), they gave you a capability-free
package.

Could you please check and see that runit and runit-init aren't in
another directory, like /usr/bin or /usr/sbin? Remember, the
poetterists are in love with the "all executables in one dir and then
symlink" philosophy, so that before the call to mount -a, /sbin has
nothing in it.


> To add injury to insult the /etc/service
> which is a link to /etc/runit/runsvdir/current gets wiped out as well.

Maybe it got moved somewhere else. Anyway, that's easy because you can
just make the symlink yourself, and document the fact.

> During the installation it ask you if the existing 3 runlevel scripts
> must be preserved and it does execute your choice (during the
> *downgrade* it will however wipe out your existing 3 scripts). At no
> time during the *upgrade* process you will see any other warning!!
> It appears the the 2 vital binaries have been moved to a new package
> 'runit-init'. 'runit-init' is *not* marked in the package 'runit' as
> a 'recommends' nor as 'suggests'.

Sounds like debian incompetence to me.

>
> Next surprise. Package 'runit-init' *cannot* co-exist with sysv-init.
> It will *uninstall* package 'sysvinit-core' and why?...because of 3
> so-called runit compatabilty scripts (shutdown, halt/reboot and
> runlevel. No diversion of these 3 sysv-executables - no, the whole
> sysvinit-core with its /sbin/init had to be removed. So the
> alternative boot-option is gone!

I thought all package manager bestowed init systems cancelled out their
alternatives. This is why I'm so partial to compiling your own Runit.
But I digress....

The practice of removing an init when installing another one is stupid.
Just like we often keep a "safe" kernel bootable, it's nice to have
different inits so that if we bork one init, we can bust back in with
the other.

With the ascension of the poetterists within the Debian developer
community, I have a feeling that, long term, any Devuan packaging of
Runit (or s6 or Epoch, for that matter) will need to be done by Devuan.
Therefore, people like you and I should begin the process of defining
what directories do what in runit, and perhaps define some best
practices. I'll throw out the first pitch...

We need to define the directory in which symlinks enable daemons. When
Daniel J Bernstein started this whole thing, that directory
was /service. But the existence of a new directory right off the root
caused purists to howl at the moon, so today that's a bad
idea. /etc/service is a possibility, except that's very confusable
with /etc/sv or whatever directory contains the actual daemon subdirs,
not the symlinks. The /etc tree branch has one huge advantage: Except
for the most unusual setups, /etc is always on the root partition.

A lot of people use /var/service. This works beautifully as long
as /etc/runit/1 can get /var mounted, so that the (later) call to
runsvdir has a mounted /var/service to work with.

But, for the sake of Devuan, I might take it a step farther and have it
be /etc/serv_runit. This way, we can also have an /etc/serv_s6 and
an /etc/serv_dtencore, so that Runit, s6 and Daemontool-encore can
coexist on the same box at the same time. This coexistance would also
require the directories containing the actual daemon supervising files
to be distinctive of their init systems:
Perhaps /etc/sv/s6, /etc/sv/runit, and /etc/sv/dtencore.

The preceding six paragraphs are based on 10 minutes thought: They're
designed to start things off, and to be modified as needed.

And yeah, Debian's practice of continually changing alternative inits
is both rude and completely expected.

SteveT

Steve Litt
August 2016 featured book: Manager's Guide to Technical Troubleshooting
Brand new, second edition
http://www.troubleshooters.com/mgr