1 |
On Thu, 21 Mar 2013 15:30:35 +0400 |
2 |
"Nikolaj Sjujskij" <sterkrig@×××××××.com> wrote: |
3 |
|
4 |
> Den 2013-03-21 14:27:42 skrev Michał Górny <mgorny@g.o>: |
5 |
> |
6 |
> > On Thu, 21 Mar 2013 10:59:49 +0400 |
7 |
> > "Nikolaj Sjujskij" <sterkrig@×××××××.com> wrote: |
8 |
> > |
9 |
> >> Den 2013-03-20 23:03:43 skrev Michał Górny <mgorny@g.o>: |
10 |
> >> |
11 |
> >> > On Wed, 20 Mar 2013 15:10:18 +0400 |
12 |
> >> > "Nikolaj Sjujskij" <sterkrig@×××××××.com> wrote: |
13 |
> >> > |
14 |
> >> >> Den 2013-03-18 02:33:50 skrev Michał Górny <mgorny@g.o>: |
15 |
> >> >> |
16 |
> >> >> > The PYTHON_COMPAT_OVERRIDE can be set in the environment to enforce |
17 |
> >> >> > a different set of Python implementations than one being |
18 |
> >> intersection |
19 |
> >> >> > of PYTHON_COMPAT and PYTHON_TARGETS. |
20 |
> >> >> > |
21 |
> >> >> > Due to technical limitations, the variable influences only the list |
22 |
> >> >> > of implementations actually used. USE flags, dependencies and other |
23 |
> >> >> > metadata variables are not modified. |
24 |
> >> >> Push it to tree, please, I'd like to test it :) |
25 |
> >> > |
26 |
> >> > Pushed :). |
27 |
> >> Yup, works fine: https://bugs.gentoo.org/show_bug.cgi?id=462566 |
28 |
> >> One minor thing. I have PYTHON_TARGETS="python2_7 python3_3" in |
29 |
> >> make.conf, |
30 |
> >> pylint ebuild has PYTHON_COMPAT=( python2_{5,6,7} python{3_1,3_2} ). I |
31 |
> >> expected `PYTHON_COMPAT_OVERRIDE="python3_3" emerge -1 pylint` to |
32 |
> >> install |
33 |
> >> pylint for both 2.7 and 3.3. Of course, it's "OVERRIDE", not "UPDATE", |
34 |
> >> but |
35 |
> >> still. |
36 |
> >> A minor thing, really, and I won't insist on changing this behaviour. |
37 |
> >> Thanks in any case :) |
38 |
> > |
39 |
> > I've decided to go this way since you can't change the IUSE. Therefore, |
40 |
> > you can't really control the enabled implementations via USE flags. If |
41 |
> > it worked like you suggested, some of the implementations would respect |
42 |
> > USE flags and some other wouldn't -- that would be confusing. |
43 |
> Agreed. But what about something like this: |
44 |
> |
45 |
> |
46 |
> --- /usr/portage/eclass/python-r1.eclass 2013-03-20 23:31:15.000000000 |
47 |
> +0400 |
48 |
> +++ python-r1.eclass 2013-03-21 15:17:58.000000000 +0400 |
49 |
> @@ -604,11 +604,11 @@ |
50 |
> ewarn |
51 |
> ewarn "Dependencies won't be satisfied, and PYTHON_TARGETS will be |
52 |
> ignored." |
53 |
> _PYTHON_COMPAT_OVERRIDE_WARNED=1 |
54 |
> fi |
55 |
> |
56 |
> - MULTIBUILD_VARIANTS=( ${PYTHON_COMPAT_OVERRIDE} ) |
57 |
> + MULTIBUILD_VARIANTS=( ${PYTHON_COMPAT_OVERRIDE} ${PYTHON_TARGETS} ) |
58 |
> return |
59 |
> fi |
60 |
> |
61 |
> _python_validate_useflags |
62 |
> _python_check_USE_PYTHON |
63 |
> |
64 |
> |
65 |
> This way eclass would use PYTHON_TARGETS, but equally "disrespect" all the |
66 |
> implementations regarding USE-flags etc, wouldn't it? :) |
67 |
> (Probably we'd have to deal with duplicates in that array, but that's only |
68 |
> an idea). |
69 |
|
70 |
Think of PYTHON_COMPAT_OVERRIDE='python2_7 python3_3'. Should 2_7 be |
71 |
enabled if it's both in override and real _COMPAT, and disabled via USE |
72 |
flag? |
73 |
|
74 |
-- |
75 |
Best regards, |
76 |
Michał Górny |