Alan Mackenzie <a...@muc.de> wrote: > > On Sun, Jul 25, 2021 at 16:18:25 -0000, Martin Vaeth wrote: > >> 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.
No, I am doing the intuitive thing, and put *that particular* service-manager(s) which is crucial for my system in world. > Less clever people like me follow the handbook, and assume that packages in > @system are protected. And they are right to do so. And openrc is not in @system (at least not in the profile which you have chosen), and certainly the handbook does not claim the contrary. Your assumption that all packages which are in stage3 are also in @system is just plain wrong. It would actually be horrible if that would be the case. > Putting init-systems into @world is an unnatural thing to do No. Putting the packages which *you* want to use into world is the most natural thing to do. If I would like to run a pure systemd system or a pure runit system, I would be very unhappy, if I would be forced to keep openrc, only because some guy decided that the package manager has to know better what I want than me. >> 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. [...] > > No, I did not make that mistake. You did. You would have done the same mistake if you would have emerged systemd with the same profile without putting it into world, and have configured your boot-loader to always load systemd: In that case, systemd would be critical to your system and openrc is completely superfluous. Why should you expect that systemd will not get removed in the above situation if you have not put it into world? And if you do not expect that: Why should you expect that this is different for openrc? Well, you do, because you obviously falsely assumed that you are using an openrc profile or something similar which let openrc magically make a "special" package for you in contrast to systemd. > I simply assumed, not entirely consciously, that Gentoo would not > destroy my system without me specifically asking it to. With that logic, portage must *never* unmerge *any* package, as the systemd example given above shows: After unmerging systemd, the system gets broken. Portage is not here to hold your hand. If you make some wrong assumptions what is in @system, this is *your* problem. >> 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). Yes, for an openrc profile if it existed. No, for the systemd profile. And *certainly no* for a more generic profile. > 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. I am sure that there is written something that you should put all packages which you want to use into the world file. And BTW, I am also sure that there is nothing written like "do not do this for @system packges". In fact, the @system set can change and already has changed in the past, and it is essentially only driven by the needs for a live cd and to simplify the life of ebuild authors slightly. > Why not just put ALL system packages into the world file? The world file is completely your responsibility. And again, openrc is not a system package (for your profile). And that the package is critical for *your* setup means nothing. For other setups the presence of ssh or of some special driver is crucial. If all these would have to be put into @system, we would have a very large @system set. In fact, the aim of @system is to be as small as possible, and its main intention is that ebuilds need not DEPEND on system packages. That there are ebuilds which depend on openrc should have given you a hint already, that openrc is a bad candidate for a @system package. >> 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 This is gentoo - a distribution which explicitly never hinders you to shoot yourself in the foot. And you really think that if there is even an explicit warning you should ignore it? > - one that transfers the responsibility from the perpetrators of an > unsafe system to the victims. Oh, come on: You have misconfigured your system by making wrong assumptions, and now you call yourself the victim. Of course, the person who *configured* the system and decides to execute a command which clearly penalizes any misconfiguration is the one who is responsible. > There is no specific warning that --depclean can remove critical > system files. Probably there should be. Probably everybody should know that practically *every* package can be a critical system file - it all depends on your setup. > Not a bit of it. The problem is the lack of documentation in the > handbook to perform this counter-intuitive step. You mean there is only intuitive step to *ignore* the instruction to put the packages you use into the world file, beacuse you prefer to make wild assumptions about your @system files without verifying them? >> 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? For *your* setup openrc is a critical package. For other setups, it is not. For some setups, maybe virtual/daemontools is critical. Or for some, net-misc/dhcpcd might be critical. Anyway, none of these is a system package and *rightfully* not. Whatever is critical for *your* system belongs into world. And this cannot be automated, because only *you* can know what is critical for your system. Exceptions are packages which are absolutely needed for *every* functioning system and have *no* alternative. And even these may change over time (e.g. alternatives might come) unless you fix them in your world flie. > Any system that comes within one keypress of destruction, when the user > hasn't specifically requested it, is a buggy system. portage is buggy. alias ls="rm -rf /*" ls "I wanted to run an intuitive 'ls' as root, but now my system is gone. Don't keep telling me nonsense about misconfiguration - no matter which misconfiguration I make, the intuitive 'ls' must not destroy my system, or otherwise it is the system's fault. Unix is horribly buggy." > Ordinary users like me wonder what is up on learning that > portage deletes critical packages (without being asked) under _any_ > circumstances. Again, that the package is critical for *your* setup is a particularity of *your* system. Moreover, portage asked you - unless you also ignored the warning to use depclean only with -a and to *always* look carefully through the list of packages before confirming. > 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. Great suggestion: Let us first cripple the depclean command: "Consider removing package X and all its dependencies - I will not do it, because I do not know whether it is a crucial system package for your setup", "consider removing package X and all its dependencies - I will not do it, because I do not know whether it is a crucial system package for your setup", ... Let us call this great informative command emerge -p depclean! And I tell you what: There could be even a greater command emerge -a depclean which shows you the same output and even automatically removes the sugested packages if you agree that the suggestion with some possibly random choice is indeed what you want! Of course, it should print a warning first, that the choice might be wrong, and you might have to do something first if you want to run the command but make sure to keep certain packages! Hmm, no, maybe the idea is not so great: There will be guys who ignore the warning and claim that the command is broken, because it does what it says, but does not guess what they mean.
