1 |
On Thu, Oct 31, 2019 at 03:49:32AM +1300, Kent Fredric wrote: |
2 |
> On Wed, 30 Oct 2019 09:26:09 -0500 |
3 |
> William Hubbs <williamh@g.o> wrote: |
4 |
> |
5 |
> > I don't know portage internals, so I have no idea what the deal with |
6 |
> > this is or how to fix it. |
7 |
> > |
8 |
> > Did you report it to the portage team? |
9 |
> |
10 |
> Report what? |
11 |
> |
12 |
> 1. Didn't have access to the box |
13 |
> 2. No way to even conceive of producing enough information to replicate |
14 |
> it reliably enough that somebody could anticipate digging into the why. |
15 |
> |
16 |
> > |
17 |
> > I've noticed it gets messy very quickly if you wait a while to upgrade |
18 |
> > your system also, so I would be curious how long the user waited to do |
19 |
> > an upgrade? |
20 |
> |
21 |
> And yeah, it was one of those cases of "bad sync length", the user in |
22 |
> question inherited the box from somebody else, and they were left to |
23 |
> pick up the pieces where the other person left off. |
24 |
> |
25 |
> And one of the common things I see that frustrates me, is generally, |
26 |
> when you see these mountains of mess, somebody tries to argue its the |
27 |
> *users* fault for not updating more frequently. |
28 |
> |
29 |
> But IMO, that's a rather distasteful buck-pass. |
30 |
> |
31 |
> The duty of a linux vendor/linux vendor maintainer is to isolate users |
32 |
> from these kinds of problems, and we're clearly failing in this way. |
33 |
> > |
34 |
> > Python is also more complex than most things because we allow multiple |
35 |
> > versions. |
36 |
> > |
37 |
> > There's no way to know whether removing virtual/rust will cause these |
38 |
> > kinds of issues, so I'm still not convinced that we shouldn't remove |
39 |
> > it. |
40 |
> |
41 |
> In light of the aforementioned axiom of "protect the user from messes", |
42 |
> I think it makes sense to approach this from the perspective of: |
43 |
> |
44 |
> If we imagine it could possibly cause a problem, until we prove it |
45 |
> doesn't and can't, we must assume it _will_ |
46 |
|
47 |
There are no ebuilds in the entire tree that directly depend on virtual/cargo; |
48 |
only cargo.eclass lists it directly. |
49 |
|
50 |
Because of that, There are two ways to get rid of virtual/cargo. |
51 |
|
52 |
1. Apply the patches in this thread. |
53 |
|
54 |
2. Create cargo-r1.eclass with the patches applied then move all consumers |
55 |
in the tree to it and remove cargo.eclass. |
56 |
|
57 |
The second option seems like overkill and would require a lot more work |
58 |
than the first, but it could be done. |
59 |
|
60 |
You are voicing concerns about either option, so is there a third |
61 |
option other than removing the dependencies from cargo.eclass and |
62 |
requiring the ebuilds to set their own dependencies? |
63 |
|
64 |
If not, I would rather see you pick one of the two options above. |
65 |
|
66 |
William |