1 |
Den 2013-03-14 20:15:55 skrev Michał Górny <mgorny@g.o>: |
2 |
|
3 |
> On Thu, 14 Mar 2013 17:10:26 +0400 |
4 |
> "Nikolaj Sjujskij" <sterkrig@×××××××.com> wrote: |
5 |
> |
6 |
>> Den 2013-03-13 23:49:33 skrev Michał Górny <mgorny@g.o>: |
7 |
>> |
8 |
>>> It couldn't work properly, so I withdrawn it. The major problem is |
9 |
>>> that metadata becomes affected by environmental variables. |
10 |
>>> |
11 |
>>> Sadly, portage can't handle that nicely. Usually, it just results in |
12 |
>>> portage 'sticking' with one particular set of USE flags on the package |
13 |
>>> and trying to use the other one at the same time. In other words, a |
14 |
>>> lot of random behavior and QA warnings. |
15 |
>>> |
16 |
>>> Probably, the nearest thing that could work is PYTHON_COMPAT_OVERRIDE |
17 |
>>> which doesn't use the USE flags but instead forces all impls listed. |
18 |
>> I see... Well, that's unfortunate, I hoped to test pylint with it, |
19 |
>> hacking ebuild just for changing PYTHON_COMPAT isn't much fun. |
20 |
> Do you consider it useful enough if PYTHON_COMPAT_OVERRIDE affected |
21 |
> the build process only? Most importantly, visible USE flags |
22 |
> and dependency resolution wouldn't be affected. |
23 |
Yep, I think so. If you mean "build and install" by "build phase". |
24 |
Suppose I do |
25 |
$ PYTHON_COMPAT_OVERRIDE="python3_3" emerge -1 dev-python/foo |
26 |
|
27 |
It fails with "bar not found" (bar isn't installed for Python 3.3 as well) |
28 |
$ PYTHON_COMPAT_OVERRIDE="python3_3" emerge -1 dev-python/bar |
29 |
dev-python/foo |
30 |
|
31 |
If modules are both OK wth Python 3.3, I want them to be installed for it |
32 |
as well. If that's the case, it'd be perfectly fine. |