From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 792851381F3 for ; Mon, 12 Nov 2012 09:34:46 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A585F21C03D; Mon, 12 Nov 2012 09:34:41 +0000 (UTC) Received: from mail-pb0-f53.google.com (mail-pb0-f53.google.com [209.85.160.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 04F3221C03D for ; Mon, 12 Nov 2012 09:34:40 +0000 (UTC) Received: by mail-pb0-f53.google.com with SMTP id jt11so91730pbb.40 for ; Mon, 12 Nov 2012 01:34:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=Cy0fVZvhlleQ48ae/avsyDv1dyLV7JXiY40u6KVvQ4w=; b=nSQPeJLHnVx7xVVvp+7hE5RX4m2IcdG5L/ZSLwTA6v0P7DiTdCZV9FiMPiv10cJNnY jI10FLvX+lRZ/OWDtYNWhJ2iWveezj5HAljZg3es9eMgm+DXbmRrpPt6rO+iLxUrTwWB 99p591UoJkFC9y1A5mvFfGPwOuSBVuxmFNsDu+Mecojp8PQpSZFenNyha4l8DVfk/mEo cMXSkJp9pO0yZDUIfdH8h/DH4wZUD5BiiloEFcmbcvO5O0bvTJGvw7VtBlXw2TJRZTTP mHrx/v3C7yCMvzNtRLGX5XtdnZfeu4DGCFpEpOWtk+UD/mRBdKhoSpZTj/B1FRG0VGaR RtrQ== Received: by 10.66.81.138 with SMTP id a10mr53332251pay.53.1352712879852; Mon, 12 Nov 2012 01:34:39 -0800 (PST) Received: from smtp.gmail.com:587 (74-95-192-101-SFBA.hfc.comcastbusiness.net. [74.95.192.101]) by mx.google.com with ESMTPS id tm8sm3930180pbc.48.2012.11.12.01.34.35 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 12 Nov 2012 01:34:36 -0800 (PST) Received: by smtp.gmail.com:587 (sSMTP sendmail emulation); Mon, 12 Nov 2012 01:34:38 -0800 Date: Mon, 12 Nov 2012 01:34:38 -0800 From: Brian Harring To: Micha?? G??rny Cc: Mike Gilbert , gentoo-python@lists.gentoo.org, python@gentoo.org Subject: Re: [gentoo-python] python-r1 <-> python.eclass package dependencies Message-ID: <20121112093438.GA6294@localhost> References: <20121110174322.656f1d67@pomiocik.lan> <20121111075248.GA23241@localhost.corp.google.com> <20121111235003.GB23241@localhost.corp.google.com> <20121112090435.76b197a1@pomiocik.lan> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Discussions centering around the Python ecosystem in Gentoo Linux X-BeenThere: gentoo-python@gentoo.org X-BeenThere: gentoo-python@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121112090435.76b197a1@pomiocik.lan> User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: 04c73449-d412-43f6-accc-ccc115767c42 X-Archives-Hash: 89348100426df30526fae0997cdb65de On Mon, Nov 12, 2012 at 09:04:35AM +0100, Micha?? G??rny wrote: > On Sun, 11 Nov 2012 15:50:03 -0800 > Brian Harring wrote: > > > On Sun, Nov 11, 2012 at 01:35:20PM -0500, Mike Gilbert wrote: > > > On Sun, Nov 11, 2012 at 2:52 AM, Brian Harring wrote: > > > > So... thus: > > > > > > > > 1) make python.eclass know of both forms of USE_PYTHON (with periods, > > > > without). > > > > 2) convert USE_PYTHON to a use expanded target > > > > 3) convert python.eclass to use it. > > > > > > > > I realize this deprecates/kills PYTHON_TARGETS; my intention here > > > > isn't to piss on the var you added, it's to choose the less disruptive > > > > option here- lesser of two evils. Starting from scratch, > > > > PYTHON_TARGETS would be fine- unfortunately we need to map existing > > > > users (and usage) from python.eclass into the replacement, > > > > constraining our choises a bit. > > > > > > > > Counter arguments? To be clear, this is the path I strongly suggest > > > > we take- if you can punch holes in the logic/arguments from above, I'd > > > > definitely back down, but the use of PYTHON_TARGETS here feels like > > > > we're setting ourselves up for unnecessary pain. Keep in mind not > > > > *all* of python.eclass notions/setup has to be chucked- we can > > > > translate certain parts of it across to ease developer/user pains. > > > > > > > > > > Following up on this and the irc conversation I eavesdropped on earlier: > > > > > > More recent versions of portage apparently filter USE_EXPAND > > > variables, so we can't utilize the old python abi values in USE_PYTHON > > > if we make that conversion. > > > > Just a note; portage's behaviour here, per the norm, is more stupid > > than that. EAPIs 0-4 are supposed to /not/ have that filtering, > > meaning portage broke it's own behaviour again. > > > > I suspect we'll retroactively change EAPIs to compensate for this, but > > I don't know for a fact; the discussion for that will occur at > > https://bugs.gentoo.org/442830 . > > I'm sorry if I miss something but don't EAPIs 0-4 define *no* behavior > for USE_EXPAND variables? (something around don't use them) You're reading that too literally. The vars weren't supposed to be screwed with- ebuilds/eclasses from that era actually relied on access of that sort (that's just how it was back then- the problem of USE_EXPAND being potentially unbound in values wasn't yet fixed). Either way, the wording /is/ such that the filtration should only be happening in EAPI5. Bluntly; portage is being buggy here, and unfortunately has been for a while. The spec/original approved behaviour is what I said- and portage in quite a few cases does exactly what I said. However, if there is (package.)use.* that is involved for that USE_EXPAND, or the group intersects IUSE, then the filtering kicks in. Meaning that if someone right now went and added linguas_ja to the base profiles use.mask, minimally 100+ ebuilds would be busted (likely more; I did a simple/stupid scan that didn't account for eclasses). Remove that use.mask filtering, suddenly the full value is again exported into all ebuild envs (eapi0-5). That's inconsistent behaviour, both for how eapi0-4 is supposed to work, and not matching eapi5 requirements since it only does partial filtering. Either way, this idiocy explains the variable results; as for how the spec/portage will be rectified, hell if I know. ~harring