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 3FDCC139694 for ; Mon, 10 Apr 2017 20:33:06 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9A36521C1BE; Mon, 10 Apr 2017 20:32:58 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (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 520B821C08A for ; Mon, 10 Apr 2017 20:32:58 +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 659AA33D3CE for ; Mon, 10 Apr 2017 20:32:56 +0000 (UTC) Message-ID: <1491856372.3444.8.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:32:52 +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: 0c3dc379-19e7-4ae3-9978-cc6e8914f99e X-Archives-Hash: 98b16cabcc9b6b8fb6adb9af8b609a5c Ühel kenal päeval, E, 10.04.2017 kell 16:17, kirjutas William L. Thomson Jr.: > On Mon, 10 Apr 2017 16:01:55 -0400 > "William L. Thomson Jr." wrote: > > > > 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. > > What about dependencies? Their slots must be increased as well right? > > In fact that effects removal. You cannot remove an old version if any > depend on that slot specifically. The USE dep requirement on the old python target will go away with the removal of it in eclass and I don't know what slots have to do with it. This circles back to first gathering the basic knowledge of how these things work right now and why, even if I don't necessarily agree with the way this was pointed out. > Rather in Java's case. If an older is removed, the ebuild does not > need > to be modified ever.... Nor if a new one is added unless it breaks. Nor does in python, it's just a janitorial process to reduce the ebuilds by 2 bytes or something. One which can be scripted and rather easily pushed thanks to not CVS anymore.