1 |
On Mon, Nov 12, 2012 at 09:04:35AM +0100, Micha?? G??rny wrote: |
2 |
> On Sun, 11 Nov 2012 15:50:03 -0800 |
3 |
> Brian Harring <ferringb@×××××.com> wrote: |
4 |
> |
5 |
> > On Sun, Nov 11, 2012 at 01:35:20PM -0500, Mike Gilbert wrote: |
6 |
> > > On Sun, Nov 11, 2012 at 2:52 AM, Brian Harring <ferringb@×××××.com> wrote: |
7 |
> > > > So... thus: |
8 |
> > > > |
9 |
> > > > 1) make python.eclass know of both forms of USE_PYTHON (with periods, |
10 |
> > > > without). |
11 |
> > > > 2) convert USE_PYTHON to a use expanded target |
12 |
> > > > 3) convert python.eclass to use it. |
13 |
> > > > |
14 |
> > > > I realize this deprecates/kills PYTHON_TARGETS; my intention here |
15 |
> > > > isn't to piss on the var you added, it's to choose the less disruptive |
16 |
> > > > option here- lesser of two evils. Starting from scratch, |
17 |
> > > > PYTHON_TARGETS would be fine- unfortunately we need to map existing |
18 |
> > > > users (and usage) from python.eclass into the replacement, |
19 |
> > > > constraining our choises a bit. |
20 |
> > > > |
21 |
> > > > Counter arguments? To be clear, this is the path I strongly suggest |
22 |
> > > > we take- if you can punch holes in the logic/arguments from above, I'd |
23 |
> > > > definitely back down, but the use of PYTHON_TARGETS here feels like |
24 |
> > > > we're setting ourselves up for unnecessary pain. Keep in mind not |
25 |
> > > > *all* of python.eclass notions/setup has to be chucked- we can |
26 |
> > > > translate certain parts of it across to ease developer/user pains. |
27 |
> > > > |
28 |
> > > |
29 |
> > > Following up on this and the irc conversation I eavesdropped on earlier: |
30 |
> > > |
31 |
> > > More recent versions of portage apparently filter USE_EXPAND |
32 |
> > > variables, so we can't utilize the old python abi values in USE_PYTHON |
33 |
> > > if we make that conversion. |
34 |
> > |
35 |
> > Just a note; portage's behaviour here, per the norm, is more stupid |
36 |
> > than that. EAPIs 0-4 are supposed to /not/ have that filtering, |
37 |
> > meaning portage broke it's own behaviour again. |
38 |
> > |
39 |
> > I suspect we'll retroactively change EAPIs to compensate for this, but |
40 |
> > I don't know for a fact; the discussion for that will occur at |
41 |
> > https://bugs.gentoo.org/442830 . |
42 |
> |
43 |
> I'm sorry if I miss something but don't EAPIs 0-4 define *no* behavior |
44 |
> for USE_EXPAND variables? (something around don't use them) |
45 |
|
46 |
You're reading that too literally. The vars weren't supposed to be |
47 |
screwed with- ebuilds/eclasses from that era actually relied on access |
48 |
of that sort (that's just how it was back then- the problem of |
49 |
USE_EXPAND being potentially unbound in values wasn't yet fixed). |
50 |
|
51 |
Either way, the wording /is/ such that the filtration should only be |
52 |
happening in EAPI5. |
53 |
|
54 |
Bluntly; portage is being buggy here, and unfortunately has been for a |
55 |
while. The spec/original approved behaviour is what I said- and |
56 |
portage in quite a few cases does exactly what I said. |
57 |
|
58 |
However, if there is (package.)use.* that is involved for that |
59 |
USE_EXPAND, or the group intersects IUSE, then the filtering kicks in. |
60 |
Meaning that if someone right now went and added linguas_ja to the |
61 |
base profiles use.mask, minimally 100+ ebuilds would be busted (likely |
62 |
more; I did a simple/stupid scan that didn't account for eclasses). |
63 |
Remove that use.mask filtering, suddenly the full value is again |
64 |
exported into all ebuild envs (eapi0-5). |
65 |
|
66 |
That's inconsistent behaviour, both for how eapi0-4 is supposed to |
67 |
work, and not matching eapi5 requirements since it only does partial |
68 |
filtering. |
69 |
|
70 |
Either way, this idiocy explains the variable results; as for how the |
71 |
spec/portage will be rectified, hell if I know. |
72 |
|
73 |
~harring |