From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-83506-garchives=archives.gentoo.org@lists.gentoo.org>
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 F0702138206
for <garchives@archives.gentoo.org>; Tue, 16 Jan 2018 13:09:56 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id A5CA8E0921;
Tue, 16 Jan 2018 13:09:50 +0000 (UTC)
Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230])
(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 2BC6AE089E
for <gentoo-dev@lists.gentoo.org>; Tue, 16 Jan 2018 13:09:50 +0000 (UTC)
Received: by mail-wm0-x230.google.com with SMTP id f3so8565721wmc.1
for <gentoo-dev@lists.gentoo.org>; Tue, 16 Jan 2018 05:09:49 -0800 (PST)
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:content-language;
bh=Nc4BynVI6km5G+cktssMjp7vCHjvh3h3Nexe6ca9vIE=;
b=XqXnoG9HnY+Cndt8I3ICkvdXNGxjIHWDNwCEHNNkwpgpfxDleTVdQI2x34ZGgKSUlH
A5+fA/ZzciELh0JiyfPolO1f6BKzHoJdVk7qxclWY7BsGX20D1c4TFioU+GXYaow/2Ux
qFn1TREnEfBGwLDR+7filPculI6InkzKwiAv3/h+PeAbr8kk9g0Af2YAo1jdjb9uIB+S
SaV1HkqecPippeuiJWGsnVOJSUjxbhyGHVUtozUwBUDfKSodVXJq8r376pJrX+kgKSSB
eLwAV3XI4ne/v99EW9kOYR05M7GDFCzSbU+aOjAdWr45rODePuDdZQz/WUq3y+bBQzoG
SgRQ==
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
:content-language;
bh=Nc4BynVI6km5G+cktssMjp7vCHjvh3h3Nexe6ca9vIE=;
b=Gutvz3rwN/zhFSD8gEfEF2TRgCcQo4/MWQLMp3Y0w6A78DSnaM48Dw/TjEJ34YH+4W
rr2JMY4RSfFtygf9lXKzEd3VoyH2JETsIHA/G1JEvpEnaiVP4RsSmfPJwfip4RciAxWs
kJB4txKBxIckUpBDndiGCELbtCYUBpinIb32vI3XxCkYEfZI9hvkWTWXzvDbS46OMyad
gV1/veqCbyPDlaVL99ZaJ5Yrod1uPB48xpm7D642ygNKh4LTqQVPOddgD8Gx6EuV6wKX
n7D9x8jKV9svnOoQ5DR02N5tcwVSZ0wFpDdjZ3V2F18DlIt9dcJk5mi4zE3E53hiLhYd
h5zQ==
X-Gm-Message-State: AKwxytcYo3TtphXNY3Bpl2jEaY6LAt01rm4t7PRJDfcu85WOak2P0u34
hg/ewLCshPRu7zH+OTle5fonhmty
X-Google-Smtp-Source: ACJfBosHOqs61zzXpMIYic/l094oBniKjRqOpbSI7ZgUdYeSDIBhdlS4M+jLS0za+adwlgMct6Ngdg==
X-Received: by 10.28.146.84 with SMTP id u81mr13081948wmd.26.1516108188557;
Tue, 16 Jan 2018 05:09:48 -0800 (PST)
Received: from [192.168.1.128] (net-188-218-203-120.cust.vodafonedsl.it. [188.218.203.120])
by smtp.gmail.com with ESMTPSA id b133sm1391635wmh.4.2018.01.16.05.09.47
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Tue, 16 Jan 2018 05:09:47 -0800 (PST)
Subject: Re: [gentoo-dev] RFC: ${PYTHON_COMPAT_ADD} in addition to
${PYTHON_COMPAT_OVERRIDE}
To: gentoo-dev@lists.gentoo.org, =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?=
<mgorny@gentoo.org>
References: <c9cd2bea-74b1-0c2a-2633-bd114140c5d5@gmail.com>
<1516089431.1598.7.camel@gentoo.org>
From: Francesco Riosa <vivo75@gmail.com>
Message-ID: <53b73b89-fd12-90a3-cf5a-52718095e6bb@gmail.com>
Date: Tue, 16 Jan 2018 14:09:45 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
Thunderbird/52.5.2
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
MIME-Version: 1.0
In-Reply-To: <1516089431.1598.7.camel@gentoo.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
X-Archives-Salt: 5ee4fa2c-6d34-40cc-91b1-02f42fc3d5fc
X-Archives-Hash: d1c575288da1321271ff72bd411eeb05
On 16/01/2018 08:57, Micha=C5=82 G=C3=B3rny wrote:
> W dniu pon, 15.01.2018 o godzinie 16=E2=88=B627=E2=80=89+0100, u=C5=BCy=
tkownik Francesco
> Riosa napisa=C5=82:
>> In late 2015 ${PYTHON_COMPAT_OVERRIDE} has been standardized and added=
>> to all python eclasses, it's useful for developers that want test and
>> mark the package for newer versions of python.
>>
>> However (unless I'm missing something) PYTHON_COMPAT_OVERRIDE is not
>> usable if:
>> - the user want only python 2.7 and 3.6 (latest) installed
>> no python 3.5
>> - don't want to mess dependencies (the warnings in the eclass are scar=
y)
> Because it is not meant to be used for that purpose, and it is not mean=
t
> to be used by users at all! It's just a quick hack for developer who
> wants to UNLIKELY(check if package works with implementation X) before
> he starts the effort on modifying PYTHON_COMPAT in ebuilds.
supposed that, but at this point I fail to see the benefit versus the
added complexity in the eclasses, however that's not my business.
>
>> So, what can be done to let the user choose it's preferred python
>> version(s) without having to build it's own overlay?
>>
>> One solution is to change ebuilds in tree to include a user variable i=
n
>> the PYTHON* arrays, example:
>>
>> -PYTHON_COMPAT=3D( python3_{4,5} )
>> +PYTHON_COMPAT=3D( python3_{4,5} ${PYTHON_COMPAT_ADD} )
>>
>> if someone want to bet that packages are ok with 3.6/latest (even befo=
re
>> a developer tested it) then add PYTHON_COMPAT_ADD=3Dpython3_6 to
>> /etc/portage/make.conf and run egencache.
>>
>> Indeed biggest problem in changing $PYTHON* variables is that metadata=
>> also change and cache is invalidated.
>>
>> However if the problem is known (*), and if the change to metadata is
>> stable per "system"/"gentoo repo clone", then the solution to the
>> problem is easy; just run $(egencache --update -j$(nproc) --repo gento=
o)
>> after each sync.
> This won't work. You are wrongly presuming that egencache regenerates
> cache unconditionally. It does so only if either ebuild or eclass
> content changed. So it worked for you once because you modified ebuilds=
> and/or eclasses. It won't work when you change PYTHON_COMPAT_ADD.
>
> I haven't checked the Portage details but it may see the metadata chang=
e
> when installing the package. Which means it would install package with
> unsatisfied dependencies (because it satisfied dependencies from cache)=
,
> then store the final dependencies and TADAAM, you've got broken
> depgraph.
ouch, that basically kill the proposal, unless portage is modified to
check known cache modifying variables, which isn't something I'd like to
create.
>
>> The most important thing is that this solution is scriptable and need =
no
>> human intervention.
> So is gpy-upgrade-impl.
It seem to do the job, one piece missing is something that monitor
gentoo repository to see if it has better version (still w/o wanted
python), an inotify for ebuilds. Suggestions?
>
>> Notice also that it's easy to have an array with duplicate values
>> PYTHON_COMPAT=3D( python3_6 python3_6 ) but at a first glance
>> _python_set_impls() is resilient to this.
>>
>> (*) In a perfect world, where global variables that can change metadat=
a
>> are known {egencache,emerge} can be made conscious and warn if the cac=
he
>> is invalid, but that's out of scope at the moment.
> This isn't perfect world. This is the exact opposite of it, it would be=
> a mess. Also, conscious tools would probably start plotting against you=
> if you'd give them such horrible tasks.
>