On Sun, Jul 25, 2021 at 2:05 PM Alan Mackenzie <a...@muc.de> wrote: > > OK, so you're clever and you know this. You know to do the > couter-intuitive thing of putting @system packages into @world. Less > clever people like me follow the handbook, and assume that packages in > @system are protected. Putting init-systems into @world is an unnatural > thing to do, and must be construed as a workaround for deficiencies in > portage.
I think you're really conflating the package manager with how some virtuals/ebuilds are configured. Portage shouldn't have service-manager-specific functionality. Nor should it do things like never uninstall things that packages say aren't needed just in case you might still be using them, when you run it with --depclean which basically is supposed to have it remove the stuff that isn't needed. All protage does is follow the dependencies. I think there is room for discussing whether daemontools should be treated as a service manager by default. I've never used it and can't speak to how it is typically used. You might want to talk to the maintainers of it to get their thoughts. > No, I did not make that mistake. I simply assumed, not entirely > consciously, that Gentoo would not destroy my system without me > specifically asking it to. It isn't like uninstalling openrc is going to "destroy your system". Worst case you could always just pass init=/bin/bash or whatever to the kernel and just reinstall it. Granted, it wouldn't really be welcome behavior. > It would be saner still to be kept in the system file (whatever that > might be). I suppose you might not care to hear that I've advocated a few times that the "system file" should disappear entirely and no packages should get special treatment. :) Granted, that has more to do with how assumed dependencies work in the repository. I don't really have a problem with confirmation before removing certain packages because reinstalling them can be quite painful. The service manager actually is one of the easier ones to fix. If you break the ability to bootstrap gcc/etc that can be a real bugger to fix. Really though posting on this list and successfully winning every argument with everybody who replies is going to do zero to change this behavior, because it is unlikely that anybody involved in this particular issue reads this list. It would make more sense to chat with the daemontools maintainer and get their thoughts on how the virtual ought to be configured as a starting point. You could always try for a second opinion/etc if that doesn't work. Plus the conversation would probably help you understand what their thinking was. -- Rich
