1 |
Hello again, Rich. |
2 |
|
3 |
On Sat, Jul 24, 2021 at 10:58:55 -0400, Rich Freeman wrote: |
4 |
> On Sat, Jul 24, 2021 at 10:46 AM Alan Mackenzie <acm@×××.de> wrote: |
5 |
|
6 |
> > On Sat, Jul 24, 2021 at 10:14:20 -0400, Rich Freeman wrote: |
7 |
> > > On Sat, Jul 24, 2021 at 9:47 AM Alan Mackenzie <acm@×××.de> wrote: |
8 |
|
9 |
> > > > So in these virtual packages, it seems by default the _last_ mentioned |
10 |
> > > > package in a || ( ... ) construct is the one --depclean keeps. It all |
11 |
> > > > has the feeling of things not having been properly thought through. |
12 |
|
13 |
> > > I'm not sure what the default is - most likely PMS just requires that |
14 |
> > > one of them be kept. |
15 |
|
16 |
> > PMS? Part of emerge? |
17 |
|
18 |
> Package Manager Specification. Specifically: |
19 |
> https://projects.gentoo.org/pms/8/pms.html#x1-760008.2.3 |
20 |
|
21 |
Ah, thanks! |
22 |
|
23 |
> All it requires is that one be present. Portage can use whatever |
24 |
> behavior it wishes to decide which to keep (assuming all installed |
25 |
> packages have their deps). |
26 |
|
27 |
> > It seems it's insisting on removing all packages but one which satisfy a |
28 |
> > virtual. Maybe that is unwise, and it should keep _all_ such packages |
29 |
> > which are currently installed. |
30 |
|
31 |
> Well, the whole point of an any-of dependency is to only require one |
32 |
> of them. Why force packages to stick around if they aren't needed? |
33 |
|
34 |
I would say all packages in @system _are_ needed, unless the user |
35 |
explicitly says otherwise. |
36 |
|
37 |
> Now, whether daemontools actually should satisfy the dependency I |
38 |
> don't want to comment on without doing more research. Surely though |
39 |
> there is little point in having openrc and systemd and runit on the |
40 |
> same system unless the user explicitly wants this (and if they do they |
41 |
> can just stick them in @world). |
42 |
|
43 |
The user might be switching between them, doing comparisons. (No, I |
44 |
don't know if this is practical.) I don't know either whether it's |
45 |
practical to boot Gentoo with just daemontools. But there are use cases |
46 |
which require both openrc and daemontools on the same system, so there's |
47 |
something not quite right about the service-manager ebuild, or emerge. |
48 |
|
49 |
> > I'm considering submitting a bug to bugs.gentoo.org, requesting that |
50 |
> > _all_ installed packages satisfying a virtual get kept. There is surely |
51 |
> > something wrong when somebody who just wants to be a user (me) has to |
52 |
> > read .ebuild files to get normal things done. |
53 |
|
54 |
> I'd be shocked if that went anywhere. I'd think the better solution |
55 |
> would be to have some kind of USE flag that tells daemontools whether |
56 |
> it is used as an actual service manager or not, though that has its |
57 |
> own issues (changing that state shouldn't require rebuilds/etc, but it |
58 |
> would). |
59 |
|
60 |
I think that would be solving the wrong problem. The fact is, it is |
61 |
easy, far too easy, to shoot yourself in the foot here. As well as |
62 |
openrc, --depclean also wanted to remove nano (the editor) for the same |
63 |
reason. That might be serious for some people. |
64 |
|
65 |
I have, in fact, submitted a bug on the "shoot yourself in the foot" |
66 |
problem. So far it's got one reply which (possibly wilfully) |
67 |
misunderstood the intent of the report, and said, much like you did "add |
68 |
daemontools to @world and the problem's solved". |
69 |
|
70 |
Maybe the answer is to regard --depclean as a tool for experts only, |
71 |
since it is capable in ordinary innocent use of rendering a system |
72 |
unusable. |
73 |
|
74 |
> In any case, you probably should have a chat with the daemontools |
75 |
> maintainer. I doubt the portage team would consider doing something |
76 |
> like this as some kind of universal policy. It would impact hundreds |
77 |
> of things that have any-of dependencies. |
78 |
|
79 |
OK. The suggestion I made in my bug report was that @system packages |
80 |
should be protected, much like @world packages are already. I don't see |
81 |
the rationale in protecting @world, but not the more important @system. |
82 |
|
83 |
> -- |
84 |
> Rich |
85 |
|
86 |
-- |
87 |
Alan Mackenzie (Nuremberg, Germany). |