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 AD5B7139694 for ; Sun, 9 Apr 2017 21:36:30 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8232221C07B; Sun, 9 Apr 2017 21:36:21 +0000 (UTC) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (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 23C28E0DD8 for ; Sun, 9 Apr 2017 21:36:21 +0000 (UTC) Received: by mail-wr0-x22c.google.com with SMTP id c55so63804792wrc.3 for ; Sun, 09 Apr 2017 14:36:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=6wuNnX2DYaBu8UFhRwXiVqTGm5sGXq8AEVZlFkh5dsE=; b=dC7a/c542gDalWU1CIpZosKHiGfdYr10LZmJlBfsGt1fyfphT3WX27byBI6bg3N9UO b6OnbhyZmo5uxJWJ82MgoSWN6ybnEmoZ82k0MErnhtA9a/Di8M7UovLEkRBTRGBTsxfV jt3vP0k02MSuVgPzwpvhaItK5xRGX/p8O0Wb3/zLL2/YN2O4ouMdrfXsm9+REhbjiLJ/ vMWRcU0pEaMwW//t4t+R+npLWSn9aO1JXeQXb3cbBjhmr8F0C3mrj0/tOkDIW+oGVNhc cotFUavCnKWAlC3kUO76nXJTc9pWpeUXFZOLByHtuDhY3Ff+EX/IRH8rF82b1N/5j0rc N/fQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=6wuNnX2DYaBu8UFhRwXiVqTGm5sGXq8AEVZlFkh5dsE=; b=cz95/ziCZN6RePr7jQ53gry3vZED3+D4O4CN7FIjmkPWgNdMHQ6KRiAsLMB+a/GCRn L64i582DXY1b4JDOexRVcLeLLwXXMrleHMHnOKcKP/EJiK6QiO+5Hrb/XODe6BTBW0zm AlxwIVzcReiPzPcwqlbI2Gdhy564U6uz9gN5aujo0ZjAL8xU08w8XBkrwzLe2iFXX2pd uoZIWs2CT9loPvKqjj9pgukExHk1+bPYsW2KOsptsXBNw8wRK6vLRHc4yFW69Z+x+tMq OKk5lTTWGq8ONCmBCbkkoP3zvA+HjXi6EadWtkBMVUNpkSHoWanYyTunf+gXL8XgvJJx Uc/Q== X-Gm-Message-State: AFeK/H1OobX7zx+trqaoSsbSwouUoM+ZYi8WGa8dqjowBnTrwRkwF5GU3foHUn5axPcvng== X-Received: by 10.223.164.137 with SMTP id g9mr34264562wrb.92.1491773779689; Sun, 09 Apr 2017 14:36:19 -0700 (PDT) Received: from [192.168.1.128] (net-5-89-218-40.cust.vodafonedsl.it. [5.89.218.40]) by smtp.gmail.com with ESMTPSA id j185sm7708889wmg.23.2017.04.09.14.36.18 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 09 Apr 2017 14:36:19 -0700 (PDT) Subject: Re: [gentoo-dev] Reverse use of Python/Ruby versions To: gentoo-dev@lists.gentoo.org References: From: Francesco Riosa Message-ID: Date: Sun, 9 Apr 2017 23:36:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 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 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: c3398d3b-6b0d-4b71-abe3-81712dac5756 X-Archives-Hash: 10c4b4dc97ef083b53053c566eac405f On 09/04/2017 18:15, William L. Thomson Jr. wrote: > Not sure if this is practical, it may be less work if the use of > Python and Ruby versions ( maybe others ) is reversed. Rather than > adding all the versions that the ebuild supports. What if it only > included versions it did not support? > > Rational > When new versions are added. Ebuilds must be updated to support the new > version. This can require editing a decent amount of ebuilds. Many may > work fine with the new version. Making this extra needless work. From a > user point of view, You cannot move to the newer version without > keeping older around till all are updated to the newer version. > > Now one could say its the same work to mark versions not supported. But > I think there is less of that. Also if something supports and older > version and not newer, it may stand out more failing. Requiring someone > to reduce to the older version, and maybe filing bugs to get it updated > to the newer version. > > Python 2.7 stuff aside. I am not sure how many Python and Ruby packages > break with a newer release. In pythons case I think once they support > Python 3.x, there is little chance if it breaking with further 3.x > releases. Not sure about Ruby. > > I could be very wrong and the present way of doing things being the > only way. However if this is feasible it may lead to less work. It > would allow all packages to move to a newer version. Also allowing > punting of older sooner. This leaves the versions solely up to the > eclasses. Then ebuilds simply mark the unsupported versions. Just like > we do now with adding versions it does support. > > Which if something was say only Python 2.7. It would have a >= to > excluded any newer version of Python. That said, we could do the same > with the current way. Saying this supports Python/Ruby >=SLOT. > > Either way I do not think the current way is the best way. You have to > add every version/slot to ebuilds that work fine with any version. When > new ones are added, the ebuild has to be touched again. When it may > work fine with a new version without requiring the ebuild to be > modified. > > This came up with some stuff requiring ruby23 as I moved to 24. Looking > around some stuff has Python 3.5 some 3.6, but all 3.4. So I will stick > to 3.4 till everything is at 3.6. Otherwise no point and still have > other versions. > > The approach mentioned above, if the packages do not have issue. I > could go ahead and switch to ruby24 and pyton 3.6 across the board. > Which I cannot do now till a bunch of ebulids have their targets > increased. > +1 to the python part, cannot speak about ruby. or totally automate the addition of python versions to ebuilds at the exact time of bumping dev-lang/python.