1 |
On Wed, 30 Oct 2019 09:26:09 -0500 |
2 |
William Hubbs <williamh@g.o> wrote: |
3 |
|
4 |
> I don't know portage internals, so I have no idea what the deal with |
5 |
> this is or how to fix it. |
6 |
> |
7 |
> Did you report it to the portage team? |
8 |
|
9 |
Report what? |
10 |
|
11 |
1. Didn't have access to the box |
12 |
2. No way to even conceive of producing enough information to replicate |
13 |
it reliably enough that somebody could anticipate digging into the why. |
14 |
|
15 |
> |
16 |
> I've noticed it gets messy very quickly if you wait a while to upgrade |
17 |
> your system also, so I would be curious how long the user waited to do |
18 |
> an upgrade? |
19 |
|
20 |
And yeah, it was one of those cases of "bad sync length", the user in |
21 |
question inherited the box from somebody else, and they were left to |
22 |
pick up the pieces where the other person left off. |
23 |
|
24 |
And one of the common things I see that frustrates me, is generally, |
25 |
when you see these mountains of mess, somebody tries to argue its the |
26 |
*users* fault for not updating more frequently. |
27 |
|
28 |
But IMO, that's a rather distasteful buck-pass. |
29 |
|
30 |
The duty of a linux vendor/linux vendor maintainer is to isolate users |
31 |
from these kinds of problems, and we're clearly failing in this way. |
32 |
> |
33 |
> Python is also more complex than most things because we allow multiple |
34 |
> versions. |
35 |
> |
36 |
> There's no way to know whether removing virtual/rust will cause these |
37 |
> kinds of issues, so I'm still not convinced that we shouldn't remove |
38 |
> it. |
39 |
|
40 |
In light of the aforementioned axiom of "protect the user from messes", |
41 |
I think it makes sense to approach this from the perspective of: |
42 |
|
43 |
If we imagine it could possibly cause a problem, until we prove it |
44 |
doesn't and can't, we must assume it _will_ |