[gentoo-dev] rfc: making sysvinit optional

[gentoo-dev] rfc: making sysvinit optional

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 486 bytes --]

All,

I have this bug against openrc:

https://bugs.gentoo.org/599468

The reason for the hard dependency on sysvinit in OpenRC no longer
exists since we now have a replacement for killall5, and some people
want to use openrc and remove sysvinit from their systems.

Before I drop the dependency on sysvinit from OpenRC, we need a way to
install both but not force sysvinit to be installed if someone removes
it later.

Does anyone have any ideas wrt how to do this?

Thanks,

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 679 bytes --]

On Wed, Jul 10, 2019 at 03:25:28PM -0500, William Hubbs wrote:
> All,
> 
> I have this bug against openrc:
> 
> https://bugs.gentoo.org/599468
> 
> The reason for the hard dependency on sysvinit in OpenRC no longer
> exists since we now have a replacement for killall5, and some people
> want to use openrc and remove sysvinit from their systems.
> 
> Before I drop the dependency on sysvinit from OpenRC, we need a way to
> install both but not force sysvinit to be installed if someone removes
> it later.
> 
> Does anyone have any ideas wrt how to do this?

Someone suggested that we need virtual/init, so I will take a look at
that possibility.

William

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[William Hubbs]

[-- Attachment #1.1: Type: text/plain, Size: 1218 bytes --]

On Wed, Jul 10, 2019 at 04:48:46PM -0500, William Hubbs wrote:
> On Wed, Jul 10, 2019 at 03:25:28PM -0500, William Hubbs wrote:
> > All,
> > 
> > I have this bug against openrc:
> > 
> > https://bugs.gentoo.org/599468
> > 
> > The reason for the hard dependency on sysvinit in OpenRC no longer
> > exists since we now have a replacement for killall5, and some people
> > want to use openrc and remove sysvinit from their systems.
> > 
> > Before I drop the dependency on sysvinit from OpenRC, we need a way to
> > install both but not force sysvinit to be installed if someone removes
> > it later.
> > 
> > Does anyone have any ideas wrt how to do this?
> 
> Someone suggested that we need virtual/init, so I will take a look at
> that possibility.

I am attaching my first crack at virtual/init.
This is a virtual for packages which provide some kind of init process.

If no one has responded in 48-72 hours, I will do the following:

1. add this to the tree
2. add it to profiles/base/packages.
3. add a sysvinit use flag to openrc, which will be off by default. When
it is on, openrc will block sysvinit since it will provide /sbin/init
and /sbin/shutdown.

Thoughts?

William


[-- Attachment #1.2: init-0.ebuild --]
[-- Type: text/plain, Size: 511 bytes --]

# Copyright 1999-2019 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2

EAPI=7

DESCRIPTION="Virtual for various init processes"
SLOT="0"
KEYWORDS="alpha amd64 arm arm64 hppa ia64 m68k ~mips ppc ppc64 ~riscv s390 sh sparc x86 ~amd64-fbsd ~x86-fbsd"
IUSE="kernel_FreeBSD kernel_linux"

RDEPEND="
		kernel_linux? (
		|| (
		sys-apps/sysvinit
			sys-apps/systemd
			sys-apps/openrc
			sys-process/runit
			virtual/daemontools
	)
	)
	kernel_FreeBSD? (
		sys-freebsd/freebsd-bin
	)"

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Michael Orlitzky]

On 7/10/19 7:16 PM, William Hubbs wrote:
> 3. add a sysvinit use flag to openrc, which will be off by default. When
> it is on, openrc will block sysvinit since it will provide /sbin/init
> and /sbin/shutdown.
> 

This logic, or maybe the name of the flag, sounds backwards to me. I
only get sysvinit when USE=sysvinit is NOT set?



> RDEPEND="
> 		kernel_linux? (
> 		|| (
> 		sys-apps/sysvinit
> 			sys-apps/systemd
> 			sys-apps/openrc
> 			sys-process/runit
> 			virtual/daemontools
> 	)

Modulo my first comment, you'll want some USE flag (un)set for
sys-apps/openrc to ensure that /sbin/init is provided.

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1458 bytes --]

On Wed, Jul 10, 2019 at 07:30:57PM -0400, Michael Orlitzky wrote:
> On 7/10/19 7:16 PM, William Hubbs wrote:
> > 3. add a sysvinit use flag to openrc, which will be off by default. When
> > it is on, openrc will block sysvinit since it will provide /sbin/init
> > and /sbin/shutdown.
> > 
> 
> This logic, or maybe the name of the flag, sounds backwards to me. I
> only get sysvinit when USE=sysvinit is NOT set?

If you don't set sys-apps/openrc[sysvinit], you would have /sbin/init
and /sbin/shutdown as they are now, from sys-apps/sysvinit.

If you do set sys-apps/openrc[sysvinit], /sbin/init and /sbin/shutdown
would become wrappers for  /sbin/openrc-init and /sbin/openrc-shutdown.

Actually, I'm thinking that the use flag can't happen until the next
OpenRC release, because I need to set up openrc-shutdown so it can shut down
a system that is booted with sysvinit first.

> 
> 
> 
> > RDEPEND="
> > 		kernel_linux? (
> > 		|| (
> > 		sys-apps/sysvinit
> > 			sys-apps/systemd
> > 			sys-apps/openrc
> > 			sys-process/runit
> > 			virtual/daemontools
> > 	)
> 
> Modulo my first comment, you'll want some USE flag (un)set for
> sys-apps/openrc to ensure that /sbin/init is provided.

I am willing to be convinced, but I'm not sure all providers of a virtual
are required to provide the same binaries. A couple of examples off the
top of my head are virtual/editor, virtual/logger and virtual/mta.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Michael Orlitzky]

On 7/10/19 8:03 PM, William Hubbs wrote:
>>
>> This logic, or maybe the name of the flag, sounds backwards to me. I
>> only get sysvinit when USE=sysvinit is NOT set?
> 
> If you don't set sys-apps/openrc[sysvinit], you would have /sbin/init
> and /sbin/shutdown as they are now, from sys-apps/sysvinit.
> 
> If you do set sys-apps/openrc[sysvinit], /sbin/init and /sbin/shutdown
> would become wrappers for  /sbin/openrc-init and /sbin/openrc-shutdown.

Which way do muons spin?


>> Modulo my first comment, you'll want some USE flag (un)set for
>> sys-apps/openrc to ensure that /sbin/init is provided.
> 
> I am willing to be convinced, but I'm not sure all providers of a virtual
> are required to provide the same binaries. A couple of examples off the
> top of my head are virtual/editor, virtual/logger and virtual/mta.

Will the system boot if you don't install sysvinit and if you don't
provide the /sbin/init wrapper for /sbin/openrc-init?

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 720 bytes --]

On Wed, Jul 10, 2019 at 08:17:06PM -0400, Michael Orlitzky wrote:

*snip*

> Will the system boot if you don't install sysvinit and if you don't
> provide the /sbin/init wrapper for /sbin/openrc-init?

No, but this is also true if you remove sysvinit and install systemd
with the sysv-utils use flag turned off, or if you install runit and
remove sysvinit.

If /sbin/init doesn't exist, you have to configure your boot loader to
pass init=/some/path/binary to the kernel.

(see the examples in /etc/default/grub).

I don't want to remove sysvinit by default. If you want to remove it,
you can, but I don't want to force that issue. That's why I don't want
to turn the use flag on by default like systemd does.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Michael Orlitzky]

On 7/10/19 11:14 PM, William Hubbs wrote:
> 
> I don't want to remove sysvinit by default. If you want to remove it,
> you can, but I don't want to force that issue. That's why I don't want
> to turn the use flag on by default like systemd does.
> 

After re-reading the bug report and sleeping on this... doesn't the USE
flag alone achieve your goals?

If you add USE=sysv-utils to OpenRC and change RDEPEND from

  RDEPEND="... sys-apps/sysvinit ... "

to

  RDEPEND="... sysv-utils? ( !sys-apps/sysvinit )
               !sysv-utils? ( sys-apps/sysvinit ) ... "

then by default, OpenRC will pull in sys-apps/sysvinit, and use its
implementations of init/shutdown. Then later if someone wants to get rid
of sys-apps/sysvinit, he has the option to uninstall sys-apps/sysvinit
and then re-emerge OpenRC with USE=sysv-utils.

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1596 bytes --]

On Thu, Jul 11, 2019 at 09:01:16AM -0400, Michael Orlitzky wrote:
> On 7/10/19 11:14 PM, William Hubbs wrote:
> > 
> > I don't want to remove sysvinit by default. If you want to remove it,
> > you can, but I don't want to force that issue. That's why I don't want
> > to turn the use flag on by default like systemd does.
> > 
> 
> After re-reading the bug report and sleeping on this... doesn't the USE
> flag alone achieve your goals?
> 
> If you add USE=sysv-utils to OpenRC and change RDEPEND from
> 
>   RDEPEND="... sys-apps/sysvinit ... "
> 
> to
> 
>   RDEPEND="... sysv-utils? ( !sys-apps/sysvinit )
>                !sysv-utils? ( sys-apps/sysvinit ) ... "
> 
> then by default, OpenRC will pull in sys-apps/sysvinit, and use its
> implementations of init/shutdown. Then later if someone wants to get rid
> of sys-apps/sysvinit, he has the option to uninstall sys-apps/sysvinit
> and then re-emerge OpenRC with USE=sysv-utils.

Sort of, but not quite. OpenRC doesn't really have an rdepend on
sysvinit at all; it is the other way around. /etc/inittab is part of
sysvinit, not openrc and this is how openrc and sysvinit are used
together. It could be argued that our sysvinit package should have the
rdepend on openrc.

But, if I do that, I need to make sure that sysvinit is installed by
default, that is one reason I'm thinking about virtual/init.

A service manager is separate from the init process, so that is also why
virtual/init should be a thing. The service manager does not have to be
in the same package as the init process.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Michael Orlitzky]

On 7/11/19 11:43 AM, William Hubbs wrote:
>>
>> then by default, OpenRC will pull in sys-apps/sysvinit, and use its
>> implementations of init/shutdown. Then later if someone wants to get rid
>> of sys-apps/sysvinit, he has the option to uninstall sys-apps/sysvinit
>> and then re-emerge OpenRC with USE=sysv-utils.
> 
> Sort of, but not quite. OpenRC doesn't really have an rdepend on
> sysvinit at all; it is the other way around. /etc/inittab is part of
> sysvinit, not openrc and this is how openrc and sysvinit are used
> together. It could be argued that our sysvinit package should have the
> rdepend on openrc.

Indeed, the fact that sys-apps/sysvinit installs an inittab that
references /sbin/openrc without depending on sys-apps/openrc already
looks very wrong to me.

Perhaps OpenRC should install its own inittab when USE=sysv-utils is
set, and when it blocks installation of sys-apps/sysvinit? In any case,
it's obvious that there's a pre-existing mess to be dealt with here and
that things aren't as clear-cut as I thought.

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 837 bytes --]

On Thu, Jul 11, 2019 at 12:11:40PM -0400, Michael Orlitzky wrote:
> Indeed, the fact that sys-apps/sysvinit installs an inittab that
> references /sbin/openrc without depending on sys-apps/openrc already
> looks very wrong to me.

Correct, that's what I have been thinking about.

> Perhaps OpenRC should install its own inittab when USE=sysv-utils is
> set, and when it blocks installation of sys-apps/sysvinit? In any case,
> it's obvious that there's a pre-existing mess to be dealt with here and
> that things aren't as clear-cut as I thought.

OpenRC has never installed an inittab because it is init-system
agnostic. It has one under /usr/share/openrc/support/sysvinit, but also
there is a README there that explains why it isn't installed.

If you use pure openrc (without sysvinit) you can rm /etc/inittab and be
fine.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Rich Freeman]

On Wed, Jul 10, 2019 at 8:03 PM William Hubbs <williamh@gentoo.org> wrote:
>
> On Wed, Jul 10, 2019 at 07:30:57PM -0400, Michael Orlitzky wrote:
> > On 7/10/19 7:16 PM, William Hubbs wrote:
> > > 3. add a sysvinit use flag to openrc, which will be off by default. When
> > > it is on, openrc will block sysvinit since it will provide /sbin/init
> > > and /sbin/shutdown.
> > >
> >
> > This logic, or maybe the name of the flag, sounds backwards to me. I
> > only get sysvinit when USE=sysvinit is NOT set?
>
> If you don't set sys-apps/openrc[sysvinit], you would have /sbin/init
> and /sbin/shutdown as they are now, from sys-apps/sysvinit.
>

Systemd already has IUSE=+sysv-utils which has a similar function:
[-      ] sysv-utils
    sys-apps/systemd: Install sysvinit compatibility symlinks and
    manpages for init, telinit, halt, poweroff, reboot, runlevel, and
    shutdown

RDEPEND="sysv-utils? ( !sys-apps/sysvinit )
         !sysv-utils? ( sys-apps/sysvinit )"

sysv-utils seems like a generic enough flag and I'd suggest that it
would be appropriate to use for openrc as well if it can install its
own implementation of these tools.

(For those who aren't aware, systemd is compatible with the sysvinit
versions of these tools, so you can run systemd with sysvinit
installed.)

-- 
Rich

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 2193 bytes --]

After chatting with Rich a bit, I'm going to reply here.

On Wed, Jul 10, 2019 at 08:17:17PM -0400, Rich Freeman wrote:
> On Wed, Jul 10, 2019 at 8:03 PM William Hubbs <williamh@gentoo.org> wrote:
> >
> > On Wed, Jul 10, 2019 at 07:30:57PM -0400, Michael Orlitzky wrote:
> > > On 7/10/19 7:16 PM, William Hubbs wrote:
> > > > 3. add a sysvinit use flag to openrc, which will be off by default. When
> > > > it is on, openrc will block sysvinit since it will provide /sbin/init
> > > > and /sbin/shutdown.
> > > >
> > >
> > > This logic, or maybe the name of the flag, sounds backwards to me. I
> > > only get sysvinit when USE=sysvinit is NOT set?
> >
> > If you don't set sys-apps/openrc[sysvinit], you would have /sbin/init
> > and /sbin/shutdown as they are now, from sys-apps/sysvinit.
> >
> 
> Systemd already has IUSE=+sysv-utils which has a similar function:
> [-      ] sysv-utils
>     sys-apps/systemd: Install sysvinit compatibility symlinks and
>     manpages for init, telinit, halt, poweroff, reboot, runlevel, and
>     shutdown

Actually, I like the name sysv-utils for this use flag; that seems to
describe better what it does.

> 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. We
 can also add sys-apps/openrc as an rdepend of sys-apps/sysvinit
 possibly. I'll take a look at that.

> sysv-utils seems like a generic enough flag and I'd suggest that it
> would be appropriate to use for openrc as well if it can install its
> own implementation of these tools.

This is where I want to go. I don't want to install the openrc
implementations by default, because I want to make it easy to dual-boot
a system, like what systemd does by default if you don't have the
sysv-utils use flag turned on.

> 
> (For those who aren't aware, systemd is compatible with the sysvinit
> versions of these tools, so you can run systemd with sysvinit
> installed.)
> 
> -- 
> Rich
> 

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Rich Freeman]

On Wed, Jul 10, 2019 at 11:02 PM William Hubbs <williamh@gentoo.org> 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?

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.

You have runit in there as well.  Can you use runit as PID1 and openrc
as your service manager?

If the only init implementations that openrc actually works with are
sysvinit and its own init, then I'd just do it the systemd way.  The
init virtual only adds value insofar as these other packages actually
provide an init that any other service manager could actually use.

If openrc works with busybox init/etc I could see an argument for
maybe having a virtual that can pull in either, though in that case it
might make sense to use that in systemd as well.

> We
>  can also add sys-apps/openrc as an rdepend of sys-apps/sysvinit
>  possibly. I'll take a look at that.

I think it makes more sense to have a service manager pull in a
compatible PID1 rather than the reverse.  For example, systemd can
pull in sysvinit for access to shutdown/telinit/etc but it makes no
sense in that case to force openrc to get installed.  You could even
use sysvinit without any other service manager.

-- 
Rich

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1839 bytes --]

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@gentoo.org> 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.

> If the only init implementations that openrc actually works with are
> sysvinit and its own init, then I'd just do it the systemd way.  The
> init virtual only adds value insofar as these other packages actually
> provide an init that any other service manager could actually use.
 
 OpenRC doesn't really care what you use for an init,  you just have to
 make the init do the equivalent of what is in /etc/inittab.

 William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Rich Freeman]

On Thu, Jul 11, 2019 at 11:56 AM William Hubbs <williamh@gentoo.org> 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@gentoo.org> 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

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 3115 bytes --]

On Thu, Jul 11, 2019 at 12:46:02PM -0400, Rich Freeman wrote:
> On Thu, Jul 11, 2019 at 11:56 AM William Hubbs <williamh@gentoo.org> 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@gentoo.org> 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.

And this would be handled by virtual/init and virtual/service-manager.
The default virtual/init would be sysvinit, and the default service
manager would be openrc since they are first in their virtuals. If you
install other providers, you have to make sure the ones you want to keep
around are in your world file, but this is not unique to this virtual.

If you are migrating, you would definitely want to be careful with
--depclean until you knew exactly what you wanted to remove or make sure
everything is in your world file that you don't want removed.

William

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Rich Freeman]

On Thu, Jul 11, 2019 at 1:22 PM William Hubbs <williamh@gentoo.org> wrote:
>
> On Thu, Jul 11, 2019 at 12:46:02PM -0400, Rich Freeman wrote:
> > On Thu, Jul 11, 2019 at 11:56 AM William Hubbs <williamh@gentoo.org> wrote:
> > >
> > > On Thu, Jul 11, 2019 at 09:42:02AM -0400, Rich Freeman wrote:
> >
> > 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.
>
> And this would be handled by virtual/init and virtual/service-manager...
>
> If you are migrating, you would definitely want to be careful with
> --depclean until you knew exactly what you wanted to remove or make sure
> everything is in your world file that you don't want removed.
>

What value is virtual/init adding though?  You don't have to be
careful with migrating if you don't use it.  You get no benefit from
using the virtual instead of just depending directly on sysvinit,
because that is the only package in the virtual that provides a
reasonable init implementation for openrc to use.

Yes, we can add that extra layer and then half the time it doesn't do
anything and the other half the time it automatically does what the
user doesn't want it to do, and users can work around it.  What it
won't ever do is make it easier to do what the user actually wants to
do.

If you do create a virtual/init then I'd just limit it to stuff that
provides a generic sysvinit implementation that will easily work with
any other service manager.  I'd argue that is sysvinit, and maybe
busybox[make-symlinks].  Maybe your openrc init implementation does,
but I haven't looked at it.  The rest simply don't provide an init
that is designed to be used with an arbitrary service manager.

Maybe to look at it another way: is this actually fixing a problem
that anybody is concerned about?  It just seems like it is giving
portage freedom to shoot the user in the foot, for little real gain.

-- 
Rich

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

[Mike Gilbert]

On Wed, Jul 10, 2019 at 11:02 PM William Hubbs <williamh@gentoo.org> wrote:
> > Systemd already has IUSE=+sysv-utils which has a similar function:
> > [-      ] sysv-utils
> >     sys-apps/systemd: Install sysvinit compatibility symlinks and
> >     manpages for init, telinit, halt, poweroff, reboot, runlevel, and
> >     shutdown
>
> Actually, I like the name sysv-utils for this use flag; that seems to
> describe better what it does.
>
> > 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.

To clarify why this strange looking dependency is there in
sys-apps/systemd: I felt it was fairly important to always have init,
shutdown, etc. available to avoid breaking other tools and to prevent
confusion. systemd is technically usable without them, but you would
need to explicitly set up your bootloader to add
init=/lib/systemd/systemd to the kernel command line, and you would
need to call systemctl directly instead of using the symlinks to shut
the system down.

Relying on any-of dependency ordering in a virtual package to
accomplish this is a bit optimistic. That can go wrong easily if the
user installs multiple providers.

> We can also add sys-apps/openrc as an rdepend of sys-apps/sysvinit possibly.

Please do not do this without consulting me first. This could
introduce a dependency conflict in sys-apps/systemd.

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 2339 bytes --]

On Thu, Jul 11, 2019 at 11:39:10AM -0400, Mike Gilbert wrote:
> On Wed, Jul 10, 2019 at 11:02 PM William Hubbs <williamh@gentoo.org> wrote:
> > > Systemd already has IUSE=+sysv-utils which has a similar function:
> > > [-      ] sysv-utils
> > >     sys-apps/systemd: Install sysvinit compatibility symlinks and
> > >     manpages for init, telinit, halt, poweroff, reboot, runlevel, and
> > >     shutdown
> >
> > Actually, I like the name sysv-utils for this use flag; that seems to
> > describe better what it does.
> >
> > > 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.
> 
> To clarify why this strange looking dependency is there in
> sys-apps/systemd: I felt it was fairly important to always have init,
> shutdown, etc. available to avoid breaking other tools and to prevent
> confusion. systemd is technically usable without them, but you would
> need to explicitly set up your bootloader to add
> init=/lib/systemd/systemd to the kernel command line, and you would
> need to call systemctl directly instead of using the symlinks to shut
> the system down.
 
 Hey Mike,

 I just looked at the systemd ebuild a second time and see that that is
 what you have, I missed it my first look, so I suppose that I should do
 things in a similar way to what you are doing.

It would be worth discussing though, probably on another thread, the
merrits of virtual/init.

> Relying on any-of dependency ordering in a virtual package to
> accomplish this is a bit optimistic. That can go wrong easily if the
> user installs multiple providers.

Where it would break is if a user uses --depclean without paying
attention to what is happening on their system, but that can cause
unexpected breakages anyway, this is not a unique situation.

> 
> > We can also add sys-apps/openrc as an rdepend of sys-apps/sysvinit possibly.
> 
> Please do not do this without consulting me first. This could
> introduce a dependency conflict in sys-apps/systemd.
 
 I see that it could, so this might be a separate topic.

 William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1981 bytes --]

I'm replying, because there is one more thing I want to add before I
head out.

On Wed, Jul 10, 2019 at 07:03:32PM -0500, William Hubbs wrote:
> On Wed, Jul 10, 2019 at 07:30:57PM -0400, Michael Orlitzky wrote:
> > On 7/10/19 7:16 PM, William Hubbs wrote:
> > > 3. add a sysvinit use flag to openrc, which will be off by default. When
> > > it is on, openrc will block sysvinit since it will provide /sbin/init
> > > and /sbin/shutdown.
> > > 
> > 
> > This logic, or maybe the name of the flag, sounds backwards to me. I
> > only get sysvinit when USE=sysvinit is NOT set?
> 
> If you don't set sys-apps/openrc[sysvinit], you would have /sbin/init
> and /sbin/shutdown as they are now, from sys-apps/sysvinit.
> 
> If you do set sys-apps/openrc[sysvinit], /sbin/init and /sbin/shutdown
> would become wrappers for  /sbin/openrc-init and /sbin/openrc-shutdown.
> 
> Actually, I'm thinking that the use flag can't happen until the next
> OpenRC release, because I need to set up openrc-shutdown so it can shut down
> a system that is booted with sysvinit first.
> 
> > 
> > 
> > 
> > > RDEPEND="
> > > 		kernel_linux? (
> > > 		|| (
> > > 		sys-apps/sysvinit

Since sysvinit is first in the rdepend it will be the first choice to be
installed. In other words, no systems would be affected unless they
forcibly unmerge sysvinit. The others below are alternatives.

> > > 			sys-apps/systemd
> > > 			sys-apps/openrc
> > > 			sys-process/runit
> > > 			virtual/daemontools

This one I need to look at, because I'm not actually sure if it provides
an init.

> > > 	)
> > 
> > Modulo my first comment, you'll want some USE flag (un)set for
> > sys-apps/openrc to ensure that /sbin/init is provided.
> 
> I am willing to be convinced, but I'm not sure all providers of a virtual
> are required to provide the same binaries. A couple of examples off the
> top of my head are virtual/editor, virtual/logger and virtual/mta.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1915 bytes --]

All,

I removed virtual/daemontools from virtual/init because it doesn't
appear to be an init process; it is just a service manager.

Here is a list of the rdepends in my proposed virtual/init with
comments.

		kernel_linux? (
		|| (
		sys-apps/sysvinit
		# If I add an RDEPEND to sysvinit for sys-apps/openrc and remove
		# the rdepend on sysvinit from sys-apps/openrc, it will line up
		# sys-apps/sysvinit with the other inits below.
		# See below for why it is important that this one is first in
		# RDEPEND.
			sys-apps/systemd
			# This blocks sysvinit if the sysvinit-utils use flag is on,
			# which it is by default.
			# If you turn off the use flag, you get the same arrangement
			# you have with openrc right now.
			sys-apps/openrc
			# If I add a sysvinit-utils use flag here, but do *NOT*
			# force it on, it wouldn't remove sysvinit, so they could
			# co-exist and you would have to switch via the boot loader.
			# In fact, they already do co-exist. you have openrc-init
			# and openrc-shutdown on your system if you have openrc
			# installed.
			sys-process/runit
			# This one has an rdepend on openrc because it uses
			# openrc in its boot sequence even if you don't use it as
			# pid 1.
			# If you are not planning to use runit as pid 1, you would
			# need to set up the init you want to use with it (upstream
			# runit doesn't care which one you use, so I don't think I
			# should either) to stay around by
			# using  something like:
			# emerge --noreplace init-app
			# to add it to the world file.
	)
	)
	kernel_FreeBSD? (
		sys-freebsd/freebsd-bin
	)

Another reason for virtual/init is, if I drop the
sys-apps/sysvinit rdepend from sys-apps/openrc, sysvinit will not be
installed by default any longer, so I would want to add this virtual
to the base profile with sysvinit listed first to make sure nothing is
broken. Mike, I don't see how this would conflict with systemd.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Mike Gilbert]

On Sat, Jul 13, 2019 at 1:51 PM William Hubbs <williamh@gentoo.org> wrote:
>
> All,
>
> I removed virtual/daemontools from virtual/init because it doesn't
> appear to be an init process; it is just a service manager.
>
> Here is a list of the rdepends in my proposed virtual/init with
> comments.
>
>                 kernel_linux? (
>                 || (
>                 sys-apps/sysvinit
>                 # If I add an RDEPEND to sysvinit for sys-apps/openrc and remove
>                 # the rdepend on sysvinit from sys-apps/openrc, it will line up
>                 # sys-apps/sysvinit with the other inits below.
>                 # See below for why it is important that this one is first in
>                 # RDEPEND.
>                         sys-apps/systemd
>                         # This blocks sysvinit if the sysvinit-utils use flag is on,
>                         # which it is by default.
>                         # If you turn off the use flag, you get the same arrangement
>                         # you have with openrc right now.
>                         sys-apps/openrc
>                         # If I add a sysvinit-utils use flag here, but do *NOT*
>                         # force it on, it wouldn't remove sysvinit, so they could
>                         # co-exist and you would have to switch via the boot loader.
>                         # In fact, they already do co-exist. you have openrc-init
>                         # and openrc-shutdown on your system if you have openrc
>                         # installed.
>                         sys-process/runit
>                         # This one has an rdepend on openrc because it uses
>                         # openrc in its boot sequence even if you don't use it as
>                         # pid 1.
>                         # If you are not planning to use runit as pid 1, you would
>                         # need to set up the init you want to use with it (upstream
>                         # runit doesn't care which one you use, so I don't think I
>                         # should either) to stay around by
>                         # using  something like:
>                         # emerge --noreplace init-app
>                         # to add it to the world file.
>         )
>         )
>         kernel_FreeBSD? (
>                 sys-freebsd/freebsd-bin
>         )
>
> Another reason for virtual/init is, if I drop the
> sys-apps/sysvinit rdepend from sys-apps/openrc, sysvinit will not be
> installed by default any longer, so I would want to add this virtual
> to the base profile with sysvinit listed first to make sure nothing is
> broken. Mike, I don't see how this would conflict with systemd.

Sorry, but this virtual still seems a bit pointless to me. You could
accomplish the same thing with an optional dependency expression in
sys-apps/openrc.

A virtual package is not the right solution here.