From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 9C763138334 for ; Wed, 30 Oct 2019 15:52:47 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 19DF2E0841; Wed, 30 Oct 2019 15:52:43 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id B21EBE0809 for ; Wed, 30 Oct 2019 15:52:42 +0000 (UTC) Received: from whubbs1.gaikai.biz (unknown [100.42.103.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: williamh) by smtp.gentoo.org (Postfix) with ESMTPSA id 4333034C591 for ; Wed, 30 Oct 2019 15:52:41 +0000 (UTC) Received: (nullmailer pid 16262 invoked by uid 1000); Wed, 30 Oct 2019 15:52:35 -0000 Date: Wed, 30 Oct 2019 10:52:35 -0500 From: William Hubbs To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual Message-ID: <20191030155235.GA16173@whubbs1.dev.av1.gaikai.org> Mail-Followup-To: gentoo-dev@lists.gentoo.org References: <20191026235511.GB16818@linux1.home> <20191027203647.2b1b10ed@katipo2.lan> <20191027170502.GA19730@linux1.home> <20191028101817.19b43ed9@katipo2.lan> <20191028153440.GA15356@whubbs1.dev.av1.gaikai.org> <7dc26dccaca7ab647c656c448ffa6a67875e2a03.camel@gentoo.org> <20191029172749.GA26121@whubbs1.dev.av1.gaikai.org> <20191030211914.7c22636a@katipo2.lan> <20191030142609.GA5419@linux1.home> <20191031034932.64e11f94@katipo2.lan> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mYCpIKhGyMATD0i+" Content-Disposition: inline In-Reply-To: <20191031034932.64e11f94@katipo2.lan> User-Agent: Mutt/1.10.1 (2018-07-13) X-Archives-Salt: 8249e351-3f00-487d-8e19-8a6c8840792b X-Archives-Hash: 5aa4b3df9ffb7f78b7e6cb540ccb014b --mYCpIKhGyMATD0i+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 31, 2019 at 03:49:32AM +1300, Kent Fredric wrote: > On Wed, 30 Oct 2019 09:26:09 -0500 > William Hubbs wrote: >=20 > > I don't know portage internals, so I have no idea what the deal with > > this is or how to fix it. > >=20 > > Did you report it to the portage team? >=20 > Report what? >=20 > 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. >=20 > >=20 > > 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? >=20 > 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. >=20 > 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. >=20 > But IMO, that's a rather distasteful buck-pass. >=20 > 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. > >=20 > > Python is also more complex than most things because we allow multiple > > versions. > >=20 > > 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. >=20 > In light of the aforementioned axiom of "protect the user from messes", > I think it makes sense to approach this from the perspective of: >=20 > 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/car= go; 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 --mYCpIKhGyMATD0i+ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTVeuxEZo4uUHOkQAluVBb0MMRlOAUCXbmxvgAKCRBuVBb0MMRl OOzJAJ49A8829P0WlP5lpz47neh5ouCooACeKOuSSK9Os26C+Mwg+QY2GAkhpsU= =uFQf -----END PGP SIGNATURE----- --mYCpIKhGyMATD0i+--