1 |
On Mon, Jan 15, 2018 at 10:27 AM, Francesco Riosa <vivo75@×××××.com> wrote: |
2 |
> |
3 |
> In late 2015 ${PYTHON_COMPAT_OVERRIDE} has been standardized and added |
4 |
> to all python eclasses, it's useful for developers that want test and |
5 |
> mark the package for newer versions of python. |
6 |
> |
7 |
> However (unless I'm missing something) PYTHON_COMPAT_OVERRIDE is not |
8 |
> usable if: |
9 |
> - the user want only python 2.7 and 3.6 (latest) installed |
10 |
> no python 3.5 |
11 |
> - don't want to mess dependencies (the warnings in the eclass are scary) |
12 |
> |
13 |
> So, what can be done to let the user choose it's preferred python |
14 |
> version(s) without having to build it's own overlay? |
15 |
> |
16 |
> One solution is to change ebuilds in tree to include a user variable in |
17 |
> the PYTHON* arrays, example: |
18 |
> |
19 |
> -PYTHON_COMPAT=( python3_{4,5} ) |
20 |
> +PYTHON_COMPAT=( python3_{4,5} ${PYTHON_COMPAT_ADD} ) |
21 |
> |
22 |
> if someone want to bet that packages are ok with 3.6/latest (even before |
23 |
> a developer tested it) then add PYTHON_COMPAT_ADD=python3_6 to |
24 |
> /etc/portage/make.conf and run egencache. |
25 |
|
26 |
I like the idea to inject values into PYTHON_COMPAT instead of |
27 |
overriding it completely. I'm pretty sure this can/should be |
28 |
implemented in the eclass without touching ebuilds. |
29 |
|
30 |
I'm not sure I really like the idea of affecting the other metadata |
31 |
variables. I can see your point about wanting to remove python |
32 |
versions that would otherwise satisfy dependencies. If metadata is |
33 |
modified this way, it would definitely be "unsupported". |
34 |
|
35 |
As far as implementation, you would probably need to write the patches for this. |
36 |
|
37 |
Also, I expect the QA team might have some objections, so you may want |
38 |
to discuss it with them (especially mgorny) before spending too much |
39 |
time on it. |