1 |
Hello, Martin. |
2 |
|
3 |
On Sun, Jul 25, 2021 at 16:18:25 -0000, Martin Vaeth wrote: |
4 |
> Alan Mackenzie <acm@×××.de> wrote: |
5 |
> > On Sun, Jul 25, 2021 at 13:26:17 +0100, Wols Lists wrote: |
6 |
|
7 |
> >> Well, it's not installed on my new system. I doubt it's installed on any |
8 |
> >> new-ish gentoo-gnome systems. So openrc itself can't be critical. |
9 |
|
10 |
> > Must you be so objectionably pedantic? It is surely clear that I was |
11 |
> > using "openrc" as a metasyntactic variable for "the current init |
12 |
> > system". If it wasn't, apologies. |
13 |
|
14 |
[ .... ] |
15 |
|
16 |
> Portage *cannot* know unless you tell it. The way to tell portage that |
17 |
> a package is crucial for *you* is to put it into the world file (or |
18 |
> into some set which is in your world file). |
19 |
|
20 |
OK, so you're clever and you know this. You know to do the |
21 |
couter-intuitive thing of putting @system packages into @world. Less |
22 |
clever people like me follow the handbook, and assume that packages in |
23 |
@system are protected. Putting init-systems into @world is an unnatural |
24 |
thing to do, and must be construed as a workaround for deficiencies in |
25 |
portage. |
26 |
|
27 |
> The mistake you made is to assume that the profile |
28 |
> profiles/default/linux/amd64/17.1/desktop (or whichever profile you |
29 |
> use) is an openrc-specific profile. It is not: It is the generic |
30 |
> profile for any init system. And it is a *good* thing that the basic |
31 |
> profiles do not force an init-system upon you which you do not want to |
32 |
> use. |
33 |
|
34 |
No, I did not make that mistake. I simply assumed, not entirely |
35 |
consciously, that Gentoo would not destroy my system without me |
36 |
specifically asking it to. |
37 |
|
38 |
> The systemd init system has its own profile, but only because systemd |
39 |
> is not only an init system, and it is therefore natural to have more |
40 |
> things in that profile than just the init system itself. |
41 |
|
42 |
> One could make also openrc, runit, daemontool profiles, but this |
43 |
> would lead to an explosion of the number of profiles (for various |
44 |
> architectures and other variants like desktop, hardened, ...), |
45 |
> and probably the only thing these profiles would do would be to |
46 |
> pull in the init system itself. It is much saner to keep this in |
47 |
> the world file. |
48 |
|
49 |
It would be saner still to be kept in the system file (whatever that |
50 |
might be). |
51 |
|
52 |
> (Once it has become standard to "combine" profiles from several |
53 |
> smaller profiles, I would suggest to have such openrc, ... profiles |
54 |
> as well, but although this is technically possible, already, it is |
55 |
> hardly documented and certainly cannot be considered at standard.) |
56 |
|
57 |
> >> It may be critical for *your* system ... :-) |
58 |
|
59 |
> > Just as systemd is for your system. |
60 |
|
61 |
> And for that reason, I have systemd in my world file. (Together with |
62 |
> openrc, BTW, because I want to be able to toggle between init systems |
63 |
> for the case that one is not running for whatever reason.) |
64 |
|
65 |
Fine for a very clever person, not so much for the rest of us. I |
66 |
installed my Gentoo in accordance with the handbook (as of 2017), and I |
67 |
don't recall any suggestion of putting critical system packages into the |
68 |
world file. Why not just put ALL system packages into the world file? |
69 |
|
70 |
> > If you'd installed daemontools you would also have come within |
71 |
> > a keystroke of destroying your system |
72 |
|
73 |
> Nope. |
74 |
|
75 |
> > as I did, on attempting emerge --depclean. You would have received no |
76 |
> > warning of any kind on installing the package, and there would be no |
77 |
> > documentation brought to your attention about the potential catastrophe. |
78 |
|
79 |
> Except for the warning that you should read *very carefully* through |
80 |
> the list of packages which are going to be removed. |
81 |
|
82 |
That looks more like a "cover your backside" warning than a real warning |
83 |
- one that transfers the responsibility from the perpetrators of an |
84 |
unsafe system to the victims. There is no specific warning that |
85 |
--depclean can remove critical system files. Probably there should be. |
86 |
|
87 |
> Surprises in misconfigured systems can occur. But the problem is |
88 |
> not the system but the misconfiguration - in your case the missing |
89 |
> world entry. |
90 |
|
91 |
Not a bit of it. The problem is the lack of documentation in the |
92 |
handbook to perform this counter-intuitive step. |
93 |
|
94 |
> > No, my problem is caused by Gentoo allowing its package system, without |
95 |
> > me doing anything strange |
96 |
|
97 |
> Relying on openrc as a critical part of the system and not telling |
98 |
> portage about it *is* something strange. |
99 |
|
100 |
Oh, come on! Relying on Gentoo not to commit suicide by deleting |
101 |
critical system packages is strange? Even you probably started out doing |
102 |
this when you first installed Gentoo. There is nothing in the handbook |
103 |
to say to do this. |
104 |
|
105 |
> > Nobody here has made any suggestions as to how this situation might be |
106 |
> > prevented in the future |
107 |
|
108 |
> The correct suggestion is to inform portage about your intention. |
109 |
> Maybe add a paragraph to the handbook about doing so (as perhaps |
110 |
> new users do no even know that they are probably using openrc). |
111 |
> Gentoo relies on informed users, not on "fixing" things over the |
112 |
> head of users. |
113 |
|
114 |
Any system that comes within one keypress of destruction, when the user |
115 |
hasn't specifically requested it, is a buggy system. portage is buggy. |
116 |
|
117 |
Your suggestion is only useful for very clever people like yourself, who |
118 |
completely master portage and all its complications before starting to |
119 |
use it. Ordinary users like me wonder what is up on learning that |
120 |
portage deletes critical packages (without being asked) under _any_ |
121 |
circumstances. |
122 |
|
123 |
> Your suggestion would go into the wrong direction: It means that if |
124 |
> a user install a package which depends on daemontools, and eventually |
125 |
> this dependency gets dropped, or the user removes the package again, |
126 |
> portage would refuse to depclean daemontools, only because it is an |
127 |
> alternative package satisfying a system dependency, and therefore - |
128 |
> according to your suggestion - portage "thinks" that you *might* rely |
129 |
> critically on it without telling portage explicitly that you do so. |
130 |
> It is one of the big advantages of gentoo that it does not have the |
131 |
> "system knows better than the user"-attitude. (Unfortunately, for some |
132 |
> other packages this is not true, but let us not discuss that here.) |
133 |
|
134 |
In that situation, portage could give the message "... has more than one |
135 |
init-system. Consider removing unused ones.", and leaving the user to |
136 |
decide what to do. |
137 |
|
138 |
-- |
139 |
Alan Mackenzie (Nuremberg, Germany). |