1 |
Alan Mackenzie wrote: |
2 |
> Hello, Neil. |
3 |
> |
4 |
> On Sun, Jul 25, 2021 at 10:03:44 +0100, Neil Bothwick wrote: |
5 |
>> On Sat, 24 Jul 2021 21:01:34 +0000, Alan Mackenzie wrote: |
6 |
>>>>> It seems it's insisting on removing all packages but one which |
7 |
>>>>> satisfy a virtual. Maybe that is unwise, and it should keep _all_ |
8 |
>>>>> such packages which are currently installed. |
9 |
>>>> Well, the whole point of an any-of dependency is to only require one |
10 |
>>>> of them. Why force packages to stick around if they aren't needed? |
11 |
>>> I would say all packages in @system _are_ needed, unless the user |
12 |
>>> explicitly says otherwise. |
13 |
>> They are, @system is a set of packages and nothing it it will be |
14 |
>> depcleaned. However, openrc is not part of @system, the virtual is. |
15 |
> Ah, that's it. So we have critical system packages which aren't part of |
16 |
> @system. I think openrc is a critical system package. |
17 |
> |
18 |
>>>> Now, whether daemontools actually should satisfy the dependency I |
19 |
>>>> don't want to comment on without doing more research. Surely though |
20 |
>>>> there is little point in having openrc and systemd and runit on the |
21 |
>>>> same system unless the user explicitly wants this (and if they do they |
22 |
>>>> can just stick them in @world). |
23 |
>>> The user might be switching between them, doing comparisons. (No, I |
24 |
>>> don't know if this is practical.) I don't know either whether it's |
25 |
>>> practical to boot Gentoo with just daemontools. But there are use cases |
26 |
>>> which require both openrc and daemontools on the same system, so there's |
27 |
>>> something not quite right about the service-manager ebuild, or emerge. |
28 |
>> That is possible, but it is also possible that this is entirely down to |
29 |
>> you installing things outside of portage and handling their dependencies |
30 |
>> manually, creating unwanted side-effects like this. |
31 |
> Quite the contrary. If I'd've stuck to the daemontools I installed from |
32 |
> a tarball, this whole thing wouldn't have happened. It's BECAUSE I |
33 |
> switched to using the portage version that this danger reared its ugly head. |
34 |
> |
35 |
>>> I think that would be solving the wrong problem. The fact is, it is |
36 |
>>> easy, far too easy, to shoot yourself in the foot here. As well as |
37 |
>>> openrc, --depclean also wanted to remove nano (the editor) for the same |
38 |
>>> reason. That might be serious for some people. |
39 |
>> It did that because you have another suitable editor installed. I don't |
40 |
>> like nano so I'm happy to install something else that satisfies |
41 |
>> virtual/editor and let depclean get rid of nano, knowing that it won't do |
42 |
>> it unless I already have a suitable alternative installed. |
43 |
>>> Maybe the answer is to regard --depclean as a tool for experts only, |
44 |
>>> since it is capable in ordinary innocent use of rendering a system |
45 |
>>> unusable. |
46 |
>> I feel it's more a case of Gentoo being a system for those that |
47 |
>> understand what they are doing with the system - with great power comes |
48 |
>> great responsibility and all that. |
49 |
> That feels needlessly patronising, Neil. I fear the Gentoo maintainers |
50 |
> will take the same attitude. Not only can the user shoot himself in the |
51 |
> foot, but it's Gentoo that provides the gun, innocently wrapped, with a |
52 |
> "press here" direction on the packaging above a hidden trigger. Nobody |
53 |
> accepts any responsibility for preventing accidents. |
54 |
> |
55 |
> The implication of what you say is that nobody should use portage |
56 |
> without understanding every last intricate detail of it. This doesn't |
57 |
> feel reasonable. |
58 |
> |
59 |
> Nobody but me seems to see anything wrong with all this. It's one thing |
60 |
> saying users should look after themselves, but surely it's quite another |
61 |
> thing to provide an obsure mechanism where one's one keypress away from |
62 |
> destroying ones system. |
63 |
> |
64 |
> I'm quite a bit less enthusiastic about Gentoo than I was a few days |
65 |
> ago. |
66 |
> |
67 |
>> -- |
68 |
>> Neil Bothwick |
69 |
>> Caution, an incorrigible punster - don't incorrige. |
70 |
|
71 |
|
72 |
The point is the same as it always has been. If you install a package |
73 |
outside of portage's knowledge, it is on you to make sure any |
74 |
dependencies are installed and to update the package itself. Surely you |
75 |
don't expect emerge/portage to know you installed a package outside its |
76 |
knowledge and to keep things it depends on by some sort of magic. When |
77 |
a user updates using emerge/portage, it can only go by what it knows. |
78 |
It can't assume something it has no knowledge of. |
79 |
|
80 |
This is why I mentioned creating a ebuild for your mail program and |
81 |
using emerge to install it. In the ebuild will be what that software |
82 |
depends on. That puts emerge/portage in the know that certain things |
83 |
are needed and not to remove them. Unless you do that, or add needed |
84 |
packages to the world file, emerge/portage will want to remove things it |
85 |
feels are not needed based on what it knows. To be honest, this is |
86 |
expected behavior. It's the whole point of --depclean. |
87 |
|
88 |
In short, this is expected behavior. If it didn't work this way, then |
89 |
I'd say there is a bug that needs to be addressed. |
90 |
|
91 |
I might add, this is why I try to never install anything outside of |
92 |
using emerge/portage. It always leads to problems like this. At the |
93 |
moment, I can think of nothing that is installed on my system that isn't |
94 |
done by emerge/portage. Even old software that is dying is still known |
95 |
to emerge/portage. When it no longer works, I'll unmerge it and move on |
96 |
to other software. At the moment, Gnome-mplayer comes to mind on that. |
97 |
Thing is, emerge/portage is aware of every single package installed on |
98 |
my system. |
99 |
|
100 |
At least you have two options that should correct the problem. Make a |
101 |
ebuild or add the needed packages for your mail program to the world |
102 |
file. Either way should make things work. I'd think the ebuild is the |
103 |
best way but one has to write the ebuild. Adding the needed packages to |
104 |
world file is easiest but could change if you upgrade the mail program. |
105 |
|
106 |
Hope you find one of those a good option. |
107 |
|
108 |
Dale |
109 |
|
110 |
:-) :-) |