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 72622139694 for ; Mon, 10 Apr 2017 20:21:38 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 05C7621C099; Mon, 10 Apr 2017 20:21:31 +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-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id AD4B221C088 for ; Mon, 10 Apr 2017 20:21:30 +0000 (UTC) Received: from [192.168.2.10] (85.253.85.240.cable.starman.ee [85.253.85.240]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: leio) by smtp.gentoo.org (Postfix) with ESMTPSA id 7E2623415B7 for ; Mon, 10 Apr 2017 20:21:28 +0000 (UTC) Message-ID: <1491855684.3444.6.camel@gentoo.org> Subject: Re: [gentoo-dev] Reverse use of Python/Ruby versions From: Mart Raudsepp To: gentoo-dev@lists.gentoo.org Date: Mon, 10 Apr 2017 23:21:24 +0300 In-Reply-To: References: <8F38F35E-A4CE-4530-880C-E409E672F253@gentoo.org> <1491844472.1661.1.camel@gentoo.org> <1491847844.1661.10.camel@gentoo.org> <1491850630.3444.2.camel@gentoo.org> <1491853895.3444.4.camel@gentoo.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6 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 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Archives-Salt: 8ac2a021-4c2f-4a56-8b1f-c8be297df933 X-Archives-Hash: 04a666e3f22d8acc91bf11c0c40d1167 Ühel kenal päeval, E, 10.04.2017 kell 16:01, kirjutas William L. Thomson Jr.: > On Mon, 10 Apr 2017 22:51:35 +0300 > Mart Raudsepp wrote: > > > > After testing they actually work with the new version, instead of > > throwing known breakages onto ~arch users. > > Ebuilds cannot use the new version till it is added to their > PYTHON_COMPAT correct? > > There does not seem to be any way around touching all ebuilds when > adding a new version. > > > > Am I missing something?   > > > > You are missing the fact that this is pure janitorial in case of > > removal of a python3 SLOT, which can be done with scripts in one > > big > > commit.  > > Ok I concede on removing older versions. Lets put old version aside. > > What about adding new? You still have to add the new version to > PYTHON_COMPAT in each ebuild right? > > What about users? Do they need do anything if they have specific > targets > set? Or all should just use Wildcard and if in ~arch have 3-4+ > pythons. > > Even if house cleaning, removing old is not an issue. You still have > adding new, and the end user experience. The user experience is suboptimal either way. Some ideas to improve that seems to be e.g something like Kent brought up. But all this requires manpower and so on to actually do; potentially also limiting potential manpower to whom has or can get some deep graph theory knowledge. Explicitly adding things is better, so you don't get some huge unknown breakages of some lower level module not working and then having to work your way towards all consumers and adding the fact they don't work there too, because a dependency doesn't work. The reverse is not feasible due to the breakages, and when you are entering automated testing to catch breakages, you might as well do automated testing and semi-automated addition to PYTHON_COMPAT for stuff that succeeds in this automated testing. We are stuck on defaulting to 3_5 mostly because not everything having 3_5 in COMPAT isn't stable yet or whatnot, combined with python teams conscious decision to tie the stabling of a new dev-lang/python SLOT (that didn't have stable versions before) to flipping default PYTHON_TARGETS as well, and then the tracker bug for that being delayed or something. Mart