1 |
Alan Mackenzie wrote: |
2 |
> Hello, Wol. |
3 |
> |
4 |
> On Sun, Jul 25, 2021 at 13:26:17 +0100, Wols Lists wrote: |
5 |
>> On 25/07/21 12:47, Alan Mackenzie wrote: |
6 |
>>>> They are, @system is a set of packages and nothing it it will be |
7 |
>>>>> depcleaned. However, openrc is not part of @system, the virtual is. |
8 |
>>> Ah, that's it. So we have critical system packages which aren't part of |
9 |
>>> @system. I think openrc is a critical system package. |
10 |
>> Well, it's not installed on my new system. I doubt it's installed on any |
11 |
>> new-ish gentoo-gnome systems. So openrc itself can't be critical. |
12 |
> Must you be so objectionably pedantic? It is surely clear that I was |
13 |
> using "openrc" as a metasyntactic variable for "the current init |
14 |
> system". If it wasn't, apologies. |
15 |
> |
16 |
>> It may be critical for *your* system ... :-) |
17 |
> Just as systemd is for your system. If you'd installed daemontools you |
18 |
> would also have come within a keystroke of destroying your system, just |
19 |
> as I did, on attempting emerge --depclean. You would have received no |
20 |
> warning of any kind on installing the package, and there would be no |
21 |
> documentation brought to your attention about the potential catastrophe. |
22 |
> |
23 |
|
24 |
Since it had a package left that satisfies the virtual, it shouldn't |
25 |
warn you. I don't recall emerge/portage ever warning about removing a |
26 |
unneeded package other than the warning when you run --depclean and it |
27 |
first starts. As said before, this is really expected behavior. |
28 |
|
29 |
>> Let's rephrase it - "openrc is one of the (optional) packages that |
30 |
>> satisfied a critical dependency". |
31 |
> If you must. |
32 |
> |
33 |
>> Your problem is caused because you have explicitly installed an |
34 |
>> alternate package that satisfies the same critical dependency. |
35 |
> No, my problem is caused by Gentoo allowing its package system, without |
36 |
> me doing anything strange, to bring my system to within a single |
37 |
> keystroke of destruction. That is a bug in any circumstance. All you |
38 |
> and most of the others have done is pointed out the mechanisms by which |
39 |
> this happened, with the implicit assumption that because that's what |
40 |
> they do, they must be right. They're not at all right. |
41 |
> |
42 |
> Nobody here has made any suggestions as to how this situation might be |
43 |
> prevented in the future, not just for me, but for the next user who |
44 |
> needs daemontools. |
45 |
> |
46 |
>> Cheers, |
47 |
>> Wol |
48 |
|
49 |
|
50 |
But the problem started when you installed a package outside of |
51 |
emerge/portage. As I pointed out earlier, since you installed a package |
52 |
outside of emerge/portage's knowledge, how do you expect it to know you |
53 |
need both packages? It's also why I suggested to either create a ebuild |
54 |
or add the packages your mail program depends on to the world file. |
55 |
Neil came up with what I think is a better solution of using sets. It |
56 |
sounds like what he is doing so it must work well enough. |
57 |
|
58 |
What we are saying is this. When you install a package outside |
59 |
emerge/portage's knowledge, you have to manage the things it depends on |
60 |
and the problems that creates. In your case, daemontools satisfied the |
61 |
virtual and emerge/portage wanted to remove openrc but it did so because |
62 |
you installed another package that satisfies that virtual. If you |
63 |
hadn't installed the other package that your mail program needs, that |
64 |
would not have happened. So, you actually created the conditions that |
65 |
made emerge/portage think it was OK to remove the package openrc. |
66 |
Again, emerge/portage doesn't know you have your mail program installed |
67 |
or what it depends on. It has no idea why you need BOTH daemontools and |
68 |
openrc installed. Luckily for you, one isn't a blocker for the other or |
69 |
that is a whole new can of worms. Also luckily you caught it was about |
70 |
to remove it as well. |
71 |
|
72 |
The lesson from this, when you install a package outside of |
73 |
emerge/portage and use emerge/portage to install packages it depends on, |
74 |
you have to be careful of the problems it creates. You can't expect |
75 |
emerge/portage to understand what you are doing and why. |
76 |
|
77 |
Dale |
78 |
|
79 |
:-) :-) |