Gentoo Archives: gentoo-user

From: Alan Mackenzie <acm@×××.de>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Re: --depclean wants to remove openrc. Yikes!
Date: Sun, 25 Jul 2021 18:06:07
Message-Id: YP2oBUmKmhNdO08O@ACM
In Reply to: [gentoo-user] Re: --depclean wants to remove openrc. Yikes! by Martin Vaeth
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).

Replies