| 1 |
On Sun, Oct 20, 2013 at 11:12 AM, Michał Górny <mgorny@g.o> wrote: |
| 2 |
> Dnia 2013-10-20, o godz. 10:53:34 |
| 3 |
> Mike Gilbert <floppym@g.o> napisał(a): |
| 4 |
> |
| 5 |
>> On Sun, Oct 20, 2013 at 3:36 AM, Michał Górny <mgorny@g.o> wrote: |
| 6 |
>> > As described in the ml, the new function does: |
| 7 |
>> > |
| 8 |
>> > * in python-any-r1, choose and set up the best installed impl, |
| 9 |
>> > |
| 10 |
>> > * in python-single-r1, read PYTHON_SINGLE_TARGET and set it up, |
| 11 |
>> > |
| 12 |
>> > * in python-r1, call python_export_best + python_wrapper_setup. |
| 13 |
>> > |
| 14 |
>> > In other words, it's a common way of getting Python build environment |
| 15 |
>> > set up in the ebuild scope. |
| 16 |
>> |
| 17 |
>> Invoking python_setup from pkg_setup in any eclass seems sub-optimal; |
| 18 |
>> especially so in python-any-r1. However, I realize there isn't a great |
| 19 |
>> place to put it. |
| 20 |
> |
| 21 |
> I don't understand. Could you rephrase? |
| 22 |
> |
| 23 |
|
| 24 |
The python stuff is generally only used in "src" phases, so pkg_setup |
| 25 |
is the wrong place for it.. As well, it would be better to set up the |
| 26 |
python wrappers and environment in a phase where the sandbox and |
| 27 |
userpriv are active to prevent permissions problems like we had with |
| 28 |
Paludis recently (there's a bug, but I'm not going to look for it). |
Archives