Alan Mackenzie wrote: > Hello, Wol. > > On Sun, Jul 25, 2021 at 13:26:17 +0100, Wols Lists wrote: >> On 25/07/21 12:47, Alan Mackenzie wrote: >>>> They are, @system is a set of packages and nothing it it will be >>>>> depcleaned. However, openrc is not part of @system, the virtual is. >>> Ah, that's it. So we have critical system packages which aren't part of >>> @system. I think openrc is a critical system package. >> Well, it's not installed on my new system. I doubt it's installed on any >> new-ish gentoo-gnome systems. So openrc itself can't be critical. > Must you be so objectionably pedantic? It is surely clear that I was > using "openrc" as a metasyntactic variable for "the current init > system". If it wasn't, apologies. > >> It may be critical for *your* system ... :-) > Just as systemd is for your system. If you'd installed daemontools you > would also have come within a keystroke of destroying your system, just > as I did, on attempting emerge --depclean. You would have received no > warning of any kind on installing the package, and there would be no > documentation brought to your attention about the potential catastrophe. >
Since it had a package left that satisfies the virtual, it shouldn't warn you. I don't recall emerge/portage ever warning about removing a unneeded package other than the warning when you run --depclean and it first starts. As said before, this is really expected behavior. >> Let's rephrase it - "openrc is one of the (optional) packages that >> satisfied a critical dependency". > If you must. > >> Your problem is caused because you have explicitly installed an >> alternate package that satisfies the same critical dependency. > No, my problem is caused by Gentoo allowing its package system, without > me doing anything strange, to bring my system to within a single > keystroke of destruction. That is a bug in any circumstance. All you > and most of the others have done is pointed out the mechanisms by which > this happened, with the implicit assumption that because that's what > they do, they must be right. They're not at all right. > > Nobody here has made any suggestions as to how this situation might be > prevented in the future, not just for me, but for the next user who > needs daemontools. > >> Cheers, >> Wol But the problem started when you installed a package outside of emerge/portage. As I pointed out earlier, since you installed a package outside of emerge/portage's knowledge, how do you expect it to know you need both packages? It's also why I suggested to either create a ebuild or add the packages your mail program depends on to the world file. Neil came up with what I think is a better solution of using sets. It sounds like what he is doing so it must work well enough. What we are saying is this. When you install a package outside emerge/portage's knowledge, you have to manage the things it depends on and the problems that creates. In your case, daemontools satisfied the virtual and emerge/portage wanted to remove openrc but it did so because you installed another package that satisfies that virtual. If you hadn't installed the other package that your mail program needs, that would not have happened. So, you actually created the conditions that made emerge/portage think it was OK to remove the package openrc. Again, emerge/portage doesn't know you have your mail program installed or what it depends on. It has no idea why you need BOTH daemontools and openrc installed. Luckily for you, one isn't a blocker for the other or that is a whole new can of worms. Also luckily you caught it was about to remove it as well. The lesson from this, when you install a package outside of emerge/portage and use emerge/portage to install packages it depends on, you have to be careful of the problems it creates. You can't expect emerge/portage to understand what you are doing and why. Dale :-) :-)
