On Sat, Jul 13, 2019 at 1:51 PM William Hubbs <willi...@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.
