On Thu, Oct 31, 2019 at 03:49:32AM +1300, Kent Fredric wrote: > On Wed, 30 Oct 2019 09:26:09 -0500 > William Hubbs <willi...@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
signature.asc
Description: Digital signature
