1 |
Den 2013-03-14 23:02:45 skrev Mike Gilbert <floppym@g.o>: |
2 |
|
3 |
> On Thu, Mar 14, 2013 at 12:15 PM, Michał Górny <mgorny@g.o> wrote: |
4 |
>> On Thu, 14 Mar 2013 17:10:26 +0400 |
5 |
>> "Nikolaj Sjujskij" <sterkrig@×××××××.com> wrote: |
6 |
>> |
7 |
>>> Den 2013-03-13 23:49:33 skrev Michał Górny <mgorny@g.o>: |
8 |
>>> |
9 |
>>>> It couldn't work properly, so I withdrawn it. The major problem is |
10 |
>>> that |
11 |
>>>> metadata becomes affected by environmental variables. |
12 |
>>>> |
13 |
>>>> Sadly, portage can't handle that nicely. Usually, it just results in |
14 |
>>>> portage 'sticking' with one particular set of USE flags on the |
15 |
>>> package |
16 |
>>>> and trying to use the other one at the same time. In other words, a |
17 |
>>> lot |
18 |
>>>> of random behavior and QA warnings. |
19 |
>>>> |
20 |
>>>> Probably, the nearest thing that could work is PYTHON_COMPAT_OVERRIDE |
21 |
>>>> which doesn't use the USE flags but instead forces all impls listed. |
22 |
>>> I see... Well, that's unfortunate, I hoped to test pylint with it, |
23 |
>>> hacking ebuild just for changing PYTHON_COMPAT isn't much fun. |
24 |
>> |
25 |
>> Do you consider it useful enough if PYTHON_COMPAT_OVERRIDE affected |
26 |
>> the build process only? Most importantly, visible USE flags |
27 |
>> and dependency resolution wouldn't be affected. |
28 |
> |
29 |
> That sounds good enough to me. I usually do initial testing with the |
30 |
> ebuild command anyway. |
31 |
That's fine for developer, who can bump ebuild afterwards, but hacking |
32 |
ebuild just to report a bug and have your changes overwritten on the next |
33 |
sync is a bit annoying :) |