virtual/init must allways depend on sys-apps/sysvinit, no matter what (or itroduce safe by default USE flags). Because sys-process/runit could be installed not to replace sysinit but as an ancillary supervisor. The next light-minded emerge --depclean after emerging runit will result in an unbootable system. Reproducible: Always Steps to Reproduce: 1. Emerge runit just to supervise several web application daemons 2. Run emerge --depclean and be inattentive 3. Reboot 4. Enjoy your unbootable system
If you want to make sure sys-apps/sysvinit stays on your system, you can add it to your world file as follows: emerge --noreplace sys-apps/sysvinit There is no need to force everyone to have sys-apps/sysvinit on their systems if they do not need or want it. Thanks, William
That way, if one want to keep one of the critical *system* packages, he should add it to the *world* list. This is not a solution but a workaround, imho. Also, the portage behavior itself is a regression and, imho, should be fixed in the tree. The problem here is runit is *not* an out of the box replacement for sysvinit. It should be configured differently, and kernel boot parameter init= should be specified as there's no /sbin/init in the runit package. I'd propose some USE flag for any package except sysvinit that virtual/init will depend on, like that: RDEPEND="kernel_linux? ( || ( >=sys-apps/sysvinit-2.86-r6 sys-process/runit[sysinit] sys-process/something-else[sysinit] ) ) kernel_FreeBSD? ( sys-freebsd/freebsd-sbin )" So if one want to replace sysvinit with runit, he'll set the sysinit flag for runit and configure it accordingly (or even the ebuild could configure itself depending on the flag). What do you think?
Hi, first, you don't need to add me to the cc since I am a member of base-system. (In reply to comment #2) > That way, if one want to keep one of the critical *system* packages, he should > add it to the *world* list. This is not a solution but a workaround, imho. > Also, the portage behavior itself is a regression and, imho, should be fixed in > the tree. There is nothing wrong with portage that needs to be fixed. The critical system package is virtual/init. It happens to have a default provider which is sys-apps/sysvinit, but we don't care which provider one you install, or you can even have more than one installed as of now because they do not collide. So, if you want multiple providers installed, it is up to you to maintain that, and you maintain the providers by adding them to the world file. > The problem here is runit is *not* an out of the box replacement for sysvinit. > It should be configured differently, and kernel boot parameter init= should be > specified as there's no /sbin/init in the runit package. That's correct; this is basically a user configuration issue. If you are replacing your init system, you should know how to do this. > I'd propose some USE flag for any package except sysvinit that virtual/init > will depend on, like that: > RDEPEND="kernel_linux? ( || ( >=sys-apps/sysvinit-2.86-r6 > sys-process/runit[sysinit] sys-process/something-else[sysinit] ) ) > kernel_FreeBSD? ( sys-freebsd/freebsd-sbin )" > > So if one want to replace sysvinit with runit, he'll set the sysinit flag for > runit and configure it accordingly (or even the ebuild could configure itself > depending on the flag). > > What do you think? Virtuals are EAPI 0, so we can't use use based dependencies. Even if we could, it would not eliminate manual configuration, because you have to re-configure your boot loader and that can't be done from an ebuild. Also, it would cause unnecessary rebuilds, because, remember that every time you change a use flag the affected package gets rebuilt.
(In reply to comment #2) > I'd propose some USE flag for any package except sysvinit that virtual/init > will depend on, like that: [...] So you do /not/ want to add the stuff you want to your world file (which would be proper Gentoo systems management practice). You also do not want to check the --depclean list for stuff you really can't do without (which would also be proper Gentoo systems management practice). Instead you want to introduce a USE flag that pulls in some dependencies (that you could and should have added to the world file). How is that an improvement? How does this preclude you from breaking the two systems management guidelines above?
If you don't think that's an issue, fine. People on #gentoo seem too agree with you, so why worry. So I'll just express my humble opinion, ok? > There is nothing wrong with portage that needs to be fixed. In the past it wasn't necessary to add any system package's dependency in the world list, even if one installed runit, minit, whatever supervisor. And no critical system dependency such as sysvinit was proposed to be depcleaned just as if it was an ordinary package. Now it is. Seems like a regression to me. > The critical system package is virtual/init. It happens to have a default > provider which is sys-apps/sysvinit, but we don't care which provider one you Imho, that default provider is the critical package - in fact, the only supported system init that works out of the box. One can live without virtual/init but not without /sbin/init on a system where sysvinit was (and still is) the system init, no matter how much daemontools clones one have installed. That's what I mean. > install, or you can even have more than one installed as of now because they do > not collide. So, if you want multiple providers installed, it is up to you to > maintain that, and you maintain the providers by adding them to the world file. Yes, runit de jure is an init provider, but not de facto, imho. It has no supported set of init scripts nor any working defaults and used just as an ancillary supervisor often than not, just like daemontools. So why put users who didn't intend to replace sysvinit at extra risk of removing it by accident? > Even if we could, it would not eliminate manual configuration, because you have But it would eliminate the risk of unintended sysvinit uninstalls. That was the reason of my proposal.
The following is just my opinion. Arguing is over. > So you do /not/ want to add the stuff you want to your world file (which would > be proper Gentoo systems management practice). Yes, I prefer to keep critical system stuff out of the world file. And it worked pretty much in every case except this one. > You also do not want to check the --depclean list for stuff you really can't do > without (which would also be proper Gentoo systems management practice). I did check the --depclean list and noticed sysvinit. It's not about what I do or what I want. It's about putting users at extra risk with no good reason (imho). > Instead you want to introduce a USE flag that pulls in some dependencies (that > you could and should have added to the world file). I'm not sure I should add system dependencies to the world file. Is there any clear statement in the documentation about that? > How is that an improvement? > How does this preclude you from breaking the two systems management guidelines > above? Well, in this case it will preclude. If runit would have the sysinit USE flag that's not set by default, and virtual/init would depend on runit[sysinit], then any time I install runit and run depclean, sysvinit would not appear among the packages proposed for removal. 100% preclusion unless I know what I'm doing and setting the sysinit flag for runit (which would have pretty clear description and the name speaking for itself pretty much).
> There is no need to force everyone to have sys-apps/sysvinit on their systems if they do not need or want it. # qlist sysvinit ... /usr/bin/utmpdump /usr/bin/lastb /usr/bin/mesg /usr/bin/last /usr/bin/wall /bin/pidof /bin/mountpoint these binaries may be use by some script > The next light-minded emerge --depclean after emerging runit will result in an unbootable system. i ran into this problem too. if someone insist on sysvinit as optional, the system should boot when i have runit installed, i.e., it should switch init to runit automatically emerge sysvinit but remove runit -> system bootable, *without* any configuration emerge runit but remove sysvinit -> system unbootable so i din't think sysvinit is optional, unless you make it switch to runit as init automatically, like any other alternatives in eselect using a symlink or something
please reopen this bug, and change it to "runit depends on sysvinit" # cat ctrlaltdel #!/bin/sh PATH=/bin:/usr/bin MSG="System is going down in 14 seconds..." # echo 'disabled.' ; exit touch /etc/runit/stopit chmod 100 /etc/runit/stopit && echo "$MSG" | wall <- this one is from sysvinit /bin/sleep 14
if runit cannot provide an init (i.e. it needs sysvinit), then it shouldn't be listed in virtual/init at all
Well it can replace init. But the ebuild does not do this itself atm. At least there must be created some /sbin/init symlink to the right place. If we do that a user AFAICT will be able to boot the system but will end up with only having some getty's But thats better than nothing. But the symlink cannot be created when sysvinit is still installed. So maybe for convenience we should add an ewarn about the fact that further manual configuration will be required if someone will remove sysvinit.
an ewarn is fine by me in runit's pkg_postinst
