| 1 |
Alan Mackenzie <acm@×××.de> wrote: |
| 2 |
> On Sun, Jul 25, 2021 at 13:26:17 +0100, Wols Lists wrote: |
| 3 |
> |
| 4 |
>> Well, it's not installed on my new system. I doubt it's installed on any |
| 5 |
>> new-ish gentoo-gnome systems. So openrc itself can't be critical. |
| 6 |
> |
| 7 |
> Must you be so objectionably pedantic? It is surely clear that I was |
| 8 |
> using "openrc" as a metasyntactic variable for "the current init |
| 9 |
> system". If it wasn't, apologies. |
| 10 |
|
| 11 |
It is the variable for *your* current init system. Like others have |
| 12 |
systemd, runit, or daemontools as *their* current init system. |
| 13 |
Portage *cannot* know unless you tell it. The way to tell portage that |
| 14 |
a package is crucial for *you* is to put it into the world file |
| 15 |
(or into some set which is in your world file). |
| 16 |
|
| 17 |
The mistake you made is to assume that the profile |
| 18 |
profiles/default/linux/amd64/17.1/desktop |
| 19 |
(or whichever profile you use) is an openrc-specific profile. |
| 20 |
It is not: It is the generic profile for any init system. And it is |
| 21 |
a *good* thing that the basic profiles do not force an init-system |
| 22 |
upon you which you do not want to use. |
| 23 |
|
| 24 |
The systemd init system has its own profile, but only because systemd |
| 25 |
is not only an init system, and it is therefore natural to have more |
| 26 |
things in that profile than just the init system itself. |
| 27 |
|
| 28 |
One could make also openrc, runit, daemontool profiles, but this |
| 29 |
would lead to an explosion of the number of profiles (for various |
| 30 |
architectures and other variants like desktop, hardened, ...), |
| 31 |
and probably the only thing these profiles would do would be to |
| 32 |
pull in the init system itself. It is much saner to keep this in |
| 33 |
the world file. |
| 34 |
|
| 35 |
(Once it has become standard to "combine" profiles from several |
| 36 |
smaller profiles, I would suggest to have such openrc, ... profiles |
| 37 |
as well, but although this is technically possible, already, it is |
| 38 |
hardly documented and certainly cannot be considered at standard.) |
| 39 |
|
| 40 |
>> It may be critical for *your* system ... :-) |
| 41 |
> |
| 42 |
> Just as systemd is for your system. |
| 43 |
|
| 44 |
And for that reason, I have systemd in my world file. (Together with |
| 45 |
openrc, BTW, because I want to be able to toggle between init systems |
| 46 |
for the case that one is not running for whatever reason.) |
| 47 |
|
| 48 |
> If you'd installed daemontools you would also have come within |
| 49 |
> a keystroke of destroying your system |
| 50 |
|
| 51 |
Nope. |
| 52 |
|
| 53 |
> as I did, on attempting emerge --depclean. You would have received no |
| 54 |
> warning of any kind on installing the package, and there would be no |
| 55 |
> documentation brought to your attention about the potential catastrophe. |
| 56 |
|
| 57 |
Except for the warning that you should read *very carefully* through |
| 58 |
the list of packages which are going to be removed. |
| 59 |
|
| 60 |
Surprises in misconfigured systems can occur. But the problem is |
| 61 |
not the system but the misconfiguration - in your case the missing |
| 62 |
world entry. |
| 63 |
|
| 64 |
> No, my problem is caused by Gentoo allowing its package system, without |
| 65 |
> me doing anything strange |
| 66 |
|
| 67 |
Relying on openrc as a critical part of the system and not telling |
| 68 |
portage about it *is* something strange. |
| 69 |
|
| 70 |
> Nobody here has made any suggestions as to how this situation might be |
| 71 |
> prevented in the future |
| 72 |
|
| 73 |
The correct suggestion is to inform portage about your intention. |
| 74 |
Maybe add a paragraph to the handbook about doing so (as perhaps |
| 75 |
new users do no even know that they are probably using openrc). |
| 76 |
Gentoo relies on informed users, not on "fixing" things over the |
| 77 |
head of users. |
| 78 |
|
| 79 |
Your suggestion would go into the wrong direction: It means that if |
| 80 |
a user install a package which depends on daemontools, and eventually |
| 81 |
this dependency gets dropped, or the user removes the package again, |
| 82 |
portage would refuse to depclean daemontools, only because it is an |
| 83 |
alternative package satisfying a system dependency, and therefore - |
| 84 |
according to your suggestion - portage "thinks" that you *might* rely |
| 85 |
critically on it without telling portage explicitly that you do so. |
| 86 |
It is one of the big advantages of gentoo that it does not have the |
| 87 |
"system knows better than the user"-attitude. (Unfortunately, for some |
| 88 |
other packages this is not true, but let us not discuss that here.) |
Archives