Hello, Martin. On Sun, Jul 25, 2021 at 16:18:25 -0000, Martin Vaeth wrote: > Alan Mackenzie <a...@muc.de> wrote: > > On Sun, Jul 25, 2021 at 13:26:17 +0100, Wols Lists wrote:
> >> 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. [ .... ] > Portage *cannot* know unless you tell it. The way to tell portage that > a package is crucial for *you* is to put it into the world file (or > into some set which is in your world file). 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. > The mistake you made is to assume that the profile > profiles/default/linux/amd64/17.1/desktop (or whichever profile you > use) is an openrc-specific profile. It is not: It is the generic > profile for any init system. And it is a *good* thing that the basic > profiles do not force an init-system upon you which you do not want to > use. 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. > The systemd init system has its own profile, but only because systemd > is not only an init system, and it is therefore natural to have more > things in that profile than just the init system itself. > One could make also openrc, runit, daemontool profiles, but this > would lead to an explosion of the number of profiles (for various > architectures and other variants like desktop, hardened, ...), > and probably the only thing these profiles would do would be to > pull in the init system itself. It is much saner to keep this in > the world file. It would be saner still to be kept in the system file (whatever that might be). > (Once it has become standard to "combine" profiles from several > smaller profiles, I would suggest to have such openrc, ... profiles > as well, but although this is technically possible, already, it is > hardly documented and certainly cannot be considered at standard.) > >> It may be critical for *your* system ... :-) > > Just as systemd is for your system. > And for that reason, I have systemd in my world file. (Together with > openrc, BTW, because I want to be able to toggle between init systems > for the case that one is not running for whatever reason.) Fine for a very clever person, not so much for the rest of us. I installed my Gentoo in accordance with the handbook (as of 2017), and I don't recall any suggestion of putting critical system packages into the world file. Why not just put ALL system packages into the world file? > > If you'd installed daemontools you would also have come within > > a keystroke of destroying your system > Nope. > > 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. > Except for the warning that you should read *very carefully* through > the list of packages which are going to be removed. That looks more like a "cover your backside" warning than a real warning - one that transfers the responsibility from the perpetrators of an unsafe system to the victims. There is no specific warning that --depclean can remove critical system files. Probably there should be. > Surprises in misconfigured systems can occur. But the problem is > not the system but the misconfiguration - in your case the missing > world entry. Not a bit of it. The problem is the lack of documentation in the handbook to perform this counter-intuitive step. > > No, my problem is caused by Gentoo allowing its package system, without > > me doing anything strange > Relying on openrc as a critical part of the system and not telling > portage about it *is* something strange. Oh, come on! Relying on Gentoo not to commit suicide by deleting critical system packages is strange? Even you probably started out doing this when you first installed Gentoo. There is nothing in the handbook to say to do this. > > Nobody here has made any suggestions as to how this situation might be > > prevented in the future > The correct suggestion is to inform portage about your intention. > Maybe add a paragraph to the handbook about doing so (as perhaps > new users do no even know that they are probably using openrc). > Gentoo relies on informed users, not on "fixing" things over the > head of users. Any system that comes within one keypress of destruction, when the user hasn't specifically requested it, is a buggy system. portage is buggy. Your suggestion is only useful for very clever people like yourself, who completely master portage and all its complications before starting to use it. Ordinary users like me wonder what is up on learning that portage deletes critical packages (without being asked) under _any_ circumstances. > Your suggestion would go into the wrong direction: It means that if > a user install a package which depends on daemontools, and eventually > this dependency gets dropped, or the user removes the package again, > portage would refuse to depclean daemontools, only because it is an > alternative package satisfying a system dependency, and therefore - > according to your suggestion - portage "thinks" that you *might* rely > critically on it without telling portage explicitly that you do so. > It is one of the big advantages of gentoo that it does not have the > "system knows better than the user"-attitude. (Unfortunately, for some > other packages this is not true, but let us not discuss that here.) In that situation, portage could give the message "... has more than one init-system. Consider removing unused ones.", and leaving the user to decide what to do. -- Alan Mackenzie (Nuremberg, Germany).
