| 1 |
On 12/04/10 16:38, Thomas Sachau wrote: |
| 2 |
> I think, the complete python code, behaviour and eclass is way too complicated to easily manage or |
| 3 |
> even understand it. E.g. why do we need 2 active versions by default? If i set e.g. python-2.6 as |
| 4 |
> default, i want everything to be installed for that and using it by default, unless i specify |
| 5 |
> something different. Nothing for python-2.7, nothing for python-3.1 or any other python version. |
| 6 |
|
| 7 |
Can we take that to another thread? This thread is about a small fix to |
| 8 |
a problem of the current eclass design, not about starting from scratch. |
| 9 |
We can still do that later if needed. |
| 10 |
|
| 11 |
|
| 12 |
> And USE_PYTHON is the wrong way to handle this. It is invisible, it only controls global settings |
| 13 |
> and together with other parts of the python eclass, it hides the dependency tree, so with |
| 14 |
> USE_PYTHON="2.6 2.7", all packages depend on both python versions, but the package manager does not |
| 15 |
> know about it. |
| 16 |
|
| 17 |
If that's the case, we may be able to fix it. Can you elabortate how |
| 18 |
dependencies are hidden and what part of the eclass is guilty? Maybe |
| 19 |
that deserves another thread, too? |
| 20 |
|
| 21 |
|
| 22 |
> I propose a package manager based solution just like the one i proposed and prepared for different |
| 23 |
> arches and crosscompilation. It is visible, easy to see and understand, allows per package control |
| 24 |
> and does leave the control to the package manager including the informations like the dependency tree. |
| 25 |
|
| 26 |
I am not objecting better fixes later. It still may be a good idea, to |
| 27 |
fix this problem before starting from scratch. |
| 28 |
|
| 29 |
|
| 30 |
>> Proposed new situation |
| 31 |
>> ====================== |
| 32 |
>> If I have a version of Python installed, it should be usable well. |
| 33 |
>> So USE_PYTHON is derived from the list of all available Python slots. |
| 34 |
>> Excluded are ABIs restricted by an ebuild, say by a line like |
| 35 |
>> |
| 36 |
>> RESTRICT_PYTHON_ABIS="3.*" |
| 37 |
>> |
| 38 |
>> for software that does not build with Python 3.x. |
| 39 |
> |
| 40 |
> I am against this proposal. I already masked python-3* on my system, because no package actually |
| 41 |
> needs it, but the current behaviour installs completly useless code for those versions. |
| 42 |
|
| 43 |
Does it? I assume when you say you masked it you also mean that you |
| 44 |
don't have Python 3.x installed? |
| 45 |
|
| 46 |
Packages are installed against an ABI iff: |
| 47 |
1) The ABI is know to the python eclass - granted |
| 48 |
2) The build is not restricting the ABI |
| 49 |
3) The related version of python is actually installed |
| 50 |
|
| 51 |
Let's do this check: Please run this command: |
| 52 |
|
| 53 |
# equery f dev-python/pyinotify | fgrep site-packages |
| 54 |
|
| 55 |
If you don't have any Python 3.x installed you should see no files for it. |
| 56 |
|
| 57 |
|
| 58 |
> Same would |
| 59 |
> happen for all other, not active versions of python. |
| 60 |
|
| 61 |
See above, please re-check if that happens for you. |
| 62 |
|
| 63 |
|
| 64 |
> One default active version should be enough, if |
| 65 |
> i want more, i can select and set it. |
| 66 |
|
| 67 |
Please elaborate in more detail on that so I'm sure I reply to the |
| 68 |
comment you actually had in mind. |
| 69 |
|
| 70 |
Best, |
| 71 |
|
| 72 |
|
| 73 |
|
| 74 |
Sebastian |
Archives