| 1 |
On Thu, Mar 14, 2013 at 12:15 PM, Michał Górny <mgorny@g.o> wrote: |
| 2 |
> On Thu, 14 Mar 2013 17:10:26 +0400 |
| 3 |
> "Nikolaj Sjujskij" <sterkrig@×××××××.com> wrote: |
| 4 |
> |
| 5 |
>> Den 2013-03-13 23:49:33 skrev Michał Górny <mgorny@g.o>: |
| 6 |
>> |
| 7 |
>> > It couldn't work properly, so I withdrawn it. The major problem is that |
| 8 |
>> > metadata becomes affected by environmental variables. |
| 9 |
>> > |
| 10 |
>> > Sadly, portage can't handle that nicely. Usually, it just results in |
| 11 |
>> > portage 'sticking' with one particular set of USE flags on the package |
| 12 |
>> > and trying to use the other one at the same time. In other words, a lot |
| 13 |
>> > of random behavior and QA warnings. |
| 14 |
>> > |
| 15 |
>> > Probably, the nearest thing that could work is PYTHON_COMPAT_OVERRIDE |
| 16 |
>> > which doesn't use the USE flags but instead forces all impls listed. |
| 17 |
>> I see... Well, that's unfortunate, I hoped to test pylint with it, |
| 18 |
>> hacking ebuild just for changing PYTHON_COMPAT isn't much fun. |
| 19 |
> |
| 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 |
|
| 24 |
That sounds good enough to me. I usually do initial testing with the |
| 25 |
ebuild command anyway. |
Archives