1 |
So, I was pinged in #gentoo-dev because dev-python/python-gflags fails now: |
2 |
|
3 |
dev-python/python-gflags-2.0: nonsolvable depset(depends) |
4 |
keyword(~x86) profile (default/linux/x86/10.0/desktop): solutions: [ |
5 |
dev-python/pypy:1.7 ] |
6 |
|
7 |
So, does the new eclass require enumeration of all supported python |
8 |
versions? If so, that's clearly broken. We really need to minimize the |
9 |
friction, such that we can add or remove versions with minimal added |
10 |
pain. |
11 |
|
12 |
Additionally, the new eclass seems to think of pypy1_7, pypy1_8 as |
13 |
different. We should probably have something that says, "this ebuild |
14 |
supports python-2.7-equivalent pypy". |
15 |
|
16 |
Proposal: |
17 |
|
18 |
- Add python2_7_pypy atom for PYTHON_COMPAT, expands to a list of pypy |
19 |
versions which is fixed in the eclass. |
20 |
- python2_5 should by default expand to include python2_6 and |
21 |
python2_7 (but not 3_*), according to a list of python versions which |
22 |
is fixed in the eclass. |
23 |
- PYTHON_COMPAT grows support for prefixing atoms with - to indicate |
24 |
missing support: python2_5 -python2_6 indicates support for 2.5 and |
25 |
2.7. |
26 |
|
27 |
Does that cover the common bases? It doesn't seem too complex. |
28 |
|
29 |
Cheers, |
30 |
|
31 |
Dirkjan |