1 |
W dniu pon, 15.01.2018 o godzinie 16∶27 +0100, użytkownik Francesco |
2 |
Riosa napisał: |
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 |
Because it is not meant to be used for that purpose, and it is not meant |
14 |
to be used by users at all! It's just a quick hack for developer who |
15 |
wants to UNLIKELY(check if package works with implementation X) before |
16 |
he starts the effort on modifying PYTHON_COMPAT in ebuilds. |
17 |
|
18 |
> So, what can be done to let the user choose it's preferred python |
19 |
> version(s) without having to build it's own overlay? |
20 |
> |
21 |
> One solution is to change ebuilds in tree to include a user variable in |
22 |
> the PYTHON* arrays, example: |
23 |
> |
24 |
> -PYTHON_COMPAT=( python3_{4,5} ) |
25 |
> +PYTHON_COMPAT=( python3_{4,5} ${PYTHON_COMPAT_ADD} ) |
26 |
> |
27 |
> if someone want to bet that packages are ok with 3.6/latest (even before |
28 |
> a developer tested it) then add PYTHON_COMPAT_ADD=python3_6 to |
29 |
> /etc/portage/make.conf and run egencache. |
30 |
> |
31 |
> Indeed biggest problem in changing $PYTHON* variables is that metadata |
32 |
> also change and cache is invalidated. |
33 |
> |
34 |
> However if the problem is known (*), and if the change to metadata is |
35 |
> stable per "system"/"gentoo repo clone", then the solution to the |
36 |
> problem is easy; just run $(egencache --update -j$(nproc) --repo gentoo) |
37 |
> after each sync. |
38 |
|
39 |
This won't work. You are wrongly presuming that egencache regenerates |
40 |
cache unconditionally. It does so only if either ebuild or eclass |
41 |
content changed. So it worked for you once because you modified ebuilds |
42 |
and/or eclasses. It won't work when you change PYTHON_COMPAT_ADD. |
43 |
|
44 |
I haven't checked the Portage details but it may see the metadata change |
45 |
when installing the package. Which means it would install package with |
46 |
unsatisfied dependencies (because it satisfied dependencies from cache), |
47 |
then store the final dependencies and TADAAM, you've got broken |
48 |
depgraph. |
49 |
|
50 |
> The most important thing is that this solution is scriptable and need no |
51 |
> human intervention. |
52 |
|
53 |
So is gpy-upgrade-impl. |
54 |
|
55 |
> |
56 |
> Notice also that it's easy to have an array with duplicate values |
57 |
> PYTHON_COMPAT=( python3_6 python3_6 ) but at a first glance |
58 |
> _python_set_impls() is resilient to this. |
59 |
> |
60 |
> (*) In a perfect world, where global variables that can change metadata |
61 |
> are known {egencache,emerge} can be made conscious and warn if the cache |
62 |
> is invalid, but that's out of scope at the moment. |
63 |
|
64 |
This isn't perfect world. This is the exact opposite of it, it would be |
65 |
a mess. Also, conscious tools would probably start plotting against you |
66 |
if you'd give them such horrible tasks. |
67 |
|
68 |
-- |
69 |
Best regards, |
70 |
Michał Górny |