Gentoo Archives: gentoo-dev

From: Rich Freeman <rich0@g.o>
To: gentoo-dev <gentoo-dev@l.g.o>
Subject: Re: [gentoo-dev] rfc: making sysvinit optional
Date: Thu, 11 Jul 2019 16:46:19
Message-Id: CAGfcS_=E3MUw-k7pBp4BCB6JmbqD+KDLdddbQJbQpkaA5RRVtg@mail.gmail.com
In Reply to: Re: [gentoo-dev] rfc: making sysvinit optional by William Hubbs
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

Replies

Subject Author
Re: [gentoo-dev] rfc: making sysvinit optional William Hubbs <williamh@g.o>