On Thu, Oct 31, 2019 at 03:49:32AM +1300, Kent Fredric wrote:
> On Wed, 30 Oct 2019 09:26:09 -0500
> William Hubbs <williamh@gentoo.org> wrote:
> 
> > I don't know portage internals, so I have no idea what the deal with
> > this is or how to fix it.
> > 
> > Did you report it to the portage team?
> 
> Report what?
> 
> 1. Didn't have access to the box
> 2. No way to even conceive of producing enough information to replicate
> it reliably enough that somebody could anticipate digging into the why.
> 
> > 
> > I've noticed it gets messy very quickly if you wait a while to upgrade
> > your system also, so I would be curious how long the user waited to do
> > an upgrade?
> 
> And yeah, it was one of those cases of "bad sync length", the user in
> question inherited the box from somebody else, and they were left to
> pick up the pieces where the other person left off.
> 
> And one of the common things I see that frustrates me, is generally,
> when you see these mountains of mess, somebody tries to argue its the
> *users* fault for not updating more frequently.
> 
> But IMO, that's a rather distasteful buck-pass.
> 
> The duty of a linux vendor/linux vendor maintainer is to isolate users
> from these kinds of problems, and we're clearly failing in this way.
> > 
> > Python is also more complex than most things because we allow multiple
> > versions.
> > 
> > There's no way to know whether removing virtual/rust will cause these
> > kinds of issues, so I'm still not convinced that we shouldn't remove
> > it.
> 
> In light of the aforementioned axiom of "protect the user from messes",
> I think it makes sense to approach this from the perspective of:
> 
>   If we imagine it could possibly cause a problem, until we prove it
>   doesn't and can't, we must assume it _will_

There are no ebuilds in the entire tree that directly depend on virtual/cargo;
only cargo.eclass lists it directly.

Because of that, There are two ways to get rid of virtual/cargo.

1. Apply the patches in this thread.

2. Create cargo-r1.eclass with the patches applied then move all consumers
in the tree to it and remove cargo.eclass.

The second option seems like overkill and would require a lot more work
than the first, but it could be done.

You are voicing concerns about either option, so is there a third
option other than removing the dependencies from cargo.eclass and
requiring the ebuilds to set their own dependencies?

If not, I would rather see you pick one of the two options above.

William