1 |
On Mon, Jan 15, 2018 at 7:05 PM, Francesco Riosa <vivo75@×××××.com> wrote: |
2 |
|
3 |
> |
4 |
> |
5 |
> On 15/01/2018 18:07, Mike Gilbert wrote: |
6 |
> > On Mon, Jan 15, 2018 at 10:27 AM, Francesco Riosa <vivo75@×××××.com> |
7 |
> wrote: |
8 |
> >> In late 2015 ${PYTHON_COMPAT_OVERRIDE} has been standardized and added |
9 |
> >> to all python eclasses, it's useful for developers that want test and |
10 |
> >> mark the package for newer versions of python. |
11 |
> >> |
12 |
> >> However (unless I'm missing something) PYTHON_COMPAT_OVERRIDE is not |
13 |
> >> usable if: |
14 |
> >> - the user want only python 2.7 and 3.6 (latest) installed |
15 |
> >> no python 3.5 |
16 |
> >> - don't want to mess dependencies (the warnings in the eclass are scary) |
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 |
> > I like the idea to inject values into PYTHON_COMPAT instead of |
31 |
> > overriding it completely. I'm pretty sure this can/should be |
32 |
> > implemented in the eclass without touching ebuilds. |
33 |
> In my mind that was to leave ebuilds developers the ability to opt out, |
34 |
> but well that could also be done in the eclasses. |
35 |
> Opt out could be beneficial for packages that only support python 2.7, |
36 |
> or where there are known and documented problems with different python |
37 |
> versions. |
38 |
> > |
39 |
> > I'm not sure I really like the idea of affecting the other metadata |
40 |
> > variables. I can see your point about wanting to remove python |
41 |
> > versions that would otherwise satisfy dependencies. If metadata is |
42 |
> > modified this way, it would definitely be "unsupported". |
43 |
> I've not tought about remove python versions, only add them (beneficial |
44 |
> for users that like to use experimental python versions) |
45 |
> However the supported python version are translated and build important |
46 |
> cached variables IUSE, DEPEND, etc. so there is no way to cleanly modify |
47 |
> those variable after the cache has been generated. |
48 |
> The only viable option is to regenerate, update or delete it. |
49 |
> |
50 |
> > |
51 |
> > As far as implementation, you would probably need to write the patches |
52 |
> for this. |
53 |
> If there is consensus that's not a problem, cannot guarantee to be fast |
54 |
> however |
55 |
> > |
56 |
> > Also, I expect the QA team might have some objections, so you may want |
57 |
> > to discuss it with them (especially mgorny) before spending too much |
58 |
> > time on it. |
59 |
> I'd like to hear mgorny opinions but that should be a more extended |
60 |
> decision than only QA and the python eclasses developer(s). |
61 |
> If nothing else because deciding that sometimes may be good to let the |
62 |
> user break the cache is a global decision and documentation need to be |
63 |
> added. |
64 |
> |
65 |
|
66 |
I'm seeing less value in this being a 'cache-breaking' exercise and more |
67 |
value in it simply being a custom eclass. |
68 |
|
69 |
If you hoist the eclass into an overlay and modify it (e.g. to set the var |
70 |
and get the deps you want) the caching |
71 |
all works out fine. |
72 |
|
73 |
1. The source of the data is the hoisted eclass. |
74 |
2. The eclass mtime changed. |
75 |
3. package managers can see that and update cache metadata for inheriting |
76 |
ebuilds. |
77 |
4. Bonus, once the cache is generated we have a valid means to see if the |
78 |
cache remains valid. |
79 |
5. Double bonus, any ebuilds not inheriting the eclass are unaffected. |
80 |
|
81 |
I'm not sure why this is so onerous. |
82 |
|
83 |
-A |