Re: [gentoo-python] python-r1 <-> python.eclass package dependencies

[Brian Harring <ferringb@gmail.com>]

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 <ferringb@gmail.com> 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 <ferringb@gmail.com> 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