1 |
On Wed, 13 Mar 2013 13:20:19 +0400 |
2 |
"Nikolaj Sjujskij" <sterkrig@×××××××.com> wrote: |
3 |
|
4 |
> Den 2012-12-13 14:44:41 skrev Michał Górny <mgorny@g.o>: |
5 |
> |
6 |
> > PYTHON_COMPAT_OVERRIDE is an environment variable which overrides |
7 |
> > the current value of PYTHON_COMPAT. |
8 |
> > |
9 |
> > Useful for testing packages with new Python implementations quickly |
10 |
> > without modifying the ebuild. Outputs a lot of noisy warnings to make |
11 |
> > sure people notice how hacky it is. |
12 |
> > |
13 |
> > Example use: |
14 |
> > |
15 |
> > $ PYTHON_COMPAT_OVERRIDE=python3_3 emerge -1v dev-python/nose |
16 |
> |
17 |
> Has it been pushed to tree? |
18 |
> |
19 |
> % grep -r PYTHON_COMPAT_OVERRIDE /usr/portage/eclass/* |
20 |
> <nothing> |
21 |
> |
22 |
> And I don't see anything related in ML archives. Have I missed something? |
23 |
|
24 |
It couldn't work properly, so I withdrawn it. The major problem is that |
25 |
metadata becomes affected by environmental variables. |
26 |
|
27 |
Sadly, portage can't handle that nicely. Usually, it just results in |
28 |
portage 'sticking' with one particular set of USE flags on the package |
29 |
and trying to use the other one at the same time. In other words, a lot |
30 |
of random behavior and QA warnings. |
31 |
|
32 |
Probably, the nearest thing that could work is PYTHON_COMPAT_OVERRIDE |
33 |
which doesn't use the USE flags but instead forces all impls listed. |
34 |
|
35 |
-- |
36 |
Best regards, |
37 |
Michał Górny |