system/s6-linux-init: new package = new init system

 This commit touches lots of things at once: it is necessary in order
to maintain consistency. The impacted packages are:

 - s6-linux-init: new package. s6-linux-init mechanism plus
booting policy. s6-linux-init conflicts with sysvinit; you can
have one or the other, depending on what init you want to boot on.
   * s6-linux-init-common: subpackage of s6-linux-init, containing
files used in the s6 supervision tree in both init cases.
Both s6-linux-init and sysvinit depend on s6-linux-init-common.

 - s6: removed s6-svscanboot, which is policy, and only used
in the sysvinit case. The s6 package is pure mechanism now.

 - utmps: adapted to the new location of the supervision tree, and
reliable files provided by s6-linux-init-common. It works as is
with both init systems.

 - gettys-openrc: had to move its invocation from "openrc sysinit"
to "openrc default", because you can't make early gettys with
s6-linux-init (no control over stage 1), and you can't have a
supervision tree before sysinit with sysvinit (because /run is
mounted very late, in boot), so the only solution that works with
both is to make gettys late services.

 - sysvinit: now has s6-svscanboot (starting the s6 supervision
tree from inittab), and a carefully crafted inittab that should
work in all cases. Getting the right order of inittab lines was
NOT easy, and I now hate sysvinit even more than I did before.

 Note that with the current version of apk, you cannot switch from
sysvinit to s6-linux-init, or vice-versa, without an error. apk
says files conflict. Because it adds the new files before removing
the old ones. It should still work with apk -f, because the
.apk-new mechanism makes it so that there's no real collision while
you're switching, but it's still ugly as fuck and needs to be fixed
in apk before we make the switch available to users.

0 files changed, 0 insertions, 0 deletions