Re: [gentoo-dev] rfc: making sysvinit optional

[Rich Freeman]

On Thu, Jul 11, 2019 at 11:56 AM William Hubbs <williamh@g.o> wrote:
>
> On Thu, Jul 11, 2019 at 09:42:02AM -0400, Rich Freeman wrote:
> > On Wed, Jul 10, 2019 at 11:02 PM William Hubbs <williamh@g.o> wrote:
> > >
> > > > RDEPEND="sysv-utils? ( !sys-apps/sysvinit )
> > > >          !sysv-utils? ( sys-apps/sysvinit )"
> > >
> > >  I like this, but the second branch (!sysv-utils) is not really needed,
> > >  because if we put sysvinit as the first RDEPEND of virtual/init, we
> > >  don't need to worry about installing it through rdepend in openrc.
> >
> > Does openrc actually work with all the stuff you have in your proposed
> > virtual/init?
>
>  Remember that OpenRC wasn't originally an init process at all. it was
>  designed to work with any init process you want it to work with. That
>  hasn't changed, I've just added an init to it which you can use if you
>  want.
>
> > For example, you have systemd in there.  I'm pretty sure you can't use
> > systemd as PID1 and then use openrc as your service manager.  I mean,
> > you probably could come up with some way to do that, but certainly
> > openrc doesn't work that way today, or systemd for that matter.
>
> There is nothing stopping you from that on the openrc side. It would
> take a lot of custom systemd units to make it work, but that is an
> exercise for the reader.
>
> > You have runit in there as well.  Can you use runit as PID1 and openrc
> > as your service manager?
>
>  Sure. There's no reason you can't.

I'm not talking about hypotheticals.  Sure, somebody could completely
dispose of the default set of systemd units and whatever runit uses as
its equivalents, and create new ones that invoke openrc and have it
take over, maybe, but none of this stuff actually exists right now.
And I'm not sure how easy it would be to even get this working since
systemd will still be trying to manage cgroups and whatever else that
openrc will presumably also be trying to do.

If somebody just installs openrc their expectation is going to be that
they get sysvinit or your substitute that actually works with openrc
out of the box.  They're not going to want to have neither installed
simply because they have runit or systemd already installed.  If
somebody is migrating from systemd to openrc that is exactly the
situation they would be in.

Neither systemd nor runit presume to be a drop-in replacement for
sysvinit to be used with other service managers.  Maybe you could
mangle it into something like this, but at that point you might as
well add python or bash to your virtual/init since you could just
write your own script for init.

My goal isn't to block user choice here - just to not just make it
trivial for users to get their system into non-working conditions to
support a configuration that nobody in their right mind is likely to
actually care to use.  I can't see the folks torn between Devuan and
Gentoo saying that they're interested in using Gentoo with openrc but
they've seen the light and it makes sense to use systemd as their PID1
with all its dbus dependencies just so that it can do nothing more
than run a few bash scripts to launch openrc.

I'd just stick with a direct conditional dependency on sysvinit.  That
is the only config that actually works with openrc reliably today.
Now, if somebody comes up with a nice openrc wrapper for runit or
systemd or whatever, then maybe add that wrapper to a virtual and
revisit the issue, and then the wrapper can pull in the init
implementation.  Then users still get a working config no matter how
portage resolves the virtual.

-- 
Rich