1 |
W dniu wto, 16.01.2018 o godzinie 14∶09 +0100, użytkownik Francesco |
2 |
Riosa napisał: |
3 |
> |
4 |
> On 16/01/2018 08:57, Michał Górny wrote: |
5 |
> > W dniu pon, 15.01.2018 o godzinie 16∶27 +0100, użytkownik Francesco |
6 |
> > Riosa napisał: |
7 |
> > > In late 2015 ${PYTHON_COMPAT_OVERRIDE} has been standardized and added |
8 |
> > > to all python eclasses, it's useful for developers that want test and |
9 |
> > > mark the package for newer versions of python. |
10 |
> > > |
11 |
> > > However (unless I'm missing something) PYTHON_COMPAT_OVERRIDE is not |
12 |
> > > usable if: |
13 |
> > > - the user want only python 2.7 and 3.6 (latest) installed |
14 |
> > > no python 3.5 |
15 |
> > > - don't want to mess dependencies (the warnings in the eclass are scary) |
16 |
> > |
17 |
> > Because it is not meant to be used for that purpose, and it is not meant |
18 |
> > to be used by users at all! It's just a quick hack for developer who |
19 |
> > wants to UNLIKELY(check if package works with implementation X) before |
20 |
> > he starts the effort on modifying PYTHON_COMPAT in ebuilds. |
21 |
> |
22 |
> supposed that, but at this point I fail to see the benefit versus the |
23 |
> added complexity in the eclasses, however that's not my business. |
24 |
> > |
25 |
> > > So, what can be done to let the user choose it's preferred python |
26 |
> > > version(s) without having to build it's own overlay? |
27 |
> > > |
28 |
> > > One solution is to change ebuilds in tree to include a user variable in |
29 |
> > > the PYTHON* arrays, example: |
30 |
> > > |
31 |
> > > -PYTHON_COMPAT=( python3_{4,5} ) |
32 |
> > > +PYTHON_COMPAT=( python3_{4,5} ${PYTHON_COMPAT_ADD} ) |
33 |
> > > |
34 |
> > > if someone want to bet that packages are ok with 3.6/latest (even before |
35 |
> > > a developer tested it) then add PYTHON_COMPAT_ADD=python3_6 to |
36 |
> > > /etc/portage/make.conf and run egencache. |
37 |
> > > |
38 |
> > > Indeed biggest problem in changing $PYTHON* variables is that metadata |
39 |
> > > also change and cache is invalidated. |
40 |
> > > |
41 |
> > > However if the problem is known (*), and if the change to metadata is |
42 |
> > > stable per "system"/"gentoo repo clone", then the solution to the |
43 |
> > > problem is easy; just run $(egencache --update -j$(nproc) --repo gentoo) |
44 |
> > > after each sync. |
45 |
> > |
46 |
> > This won't work. You are wrongly presuming that egencache regenerates |
47 |
> > cache unconditionally. It does so only if either ebuild or eclass |
48 |
> > content changed. So it worked for you once because you modified ebuilds |
49 |
> > and/or eclasses. It won't work when you change PYTHON_COMPAT_ADD. |
50 |
> > |
51 |
> > I haven't checked the Portage details but it may see the metadata change |
52 |
> > when installing the package. Which means it would install package with |
53 |
> > unsatisfied dependencies (because it satisfied dependencies from cache), |
54 |
> > then store the final dependencies and TADAAM, you've got broken |
55 |
> > depgraph. |
56 |
> |
57 |
> ouch, that basically kill the proposal, unless portage is modified to |
58 |
> check known cache modifying variables, which isn't something I'd like to |
59 |
> create. |
60 |
> > |
61 |
> > > The most important thing is that this solution is scriptable and need no |
62 |
> > > human intervention. |
63 |
> > |
64 |
> > So is gpy-upgrade-impl. |
65 |
> |
66 |
> It seem to do the job, one piece missing is something that monitor |
67 |
> gentoo repository to see if it has better version (still w/o wanted |
68 |
> python), an inotify for ebuilds. Suggestions? |
69 |
|
70 |
None. I think Alec's idea would work better for you. |
71 |
|
72 |
-- |
73 |
Best regards, |
74 |
Michał Górny |