On 12/04/10 16:38, Thomas Sachau wrote: > I think, the complete python code, behaviour and eclass is way too > complicated to easily manage or > even understand it. E.g. why do we need 2 active versions by default? If i > set e.g. python-2.6 as > default, i want everything to be installed for that and using it by default, > unless i specify > something different. Nothing for python-2.7, nothing for python-3.1 or any > other python version.
Can we take that to another thread? This thread is about a small fix to a problem of the current eclass design, not about starting from scratch. We can still do that later if needed. > And USE_PYTHON is the wrong way to handle this. It is invisible, it only > controls global settings > and together with other parts of the python eclass, it hides the dependency > tree, so with > USE_PYTHON="2.6 2.7", all packages depend on both python versions, but the > package manager does not > know about it. If that's the case, we may be able to fix it. Can you elabortate how dependencies are hidden and what part of the eclass is guilty? Maybe that deserves another thread, too? > I propose a package manager based solution just like the one i proposed and > prepared for different > arches and crosscompilation. It is visible, easy to see and understand, > allows per package control > and does leave the control to the package manager including the informations > like the dependency tree. I am not objecting better fixes later. It still may be a good idea, to fix this problem before starting from scratch. >> Proposed new situation >> ====================== >> If I have a version of Python installed, it should be usable well. >> So USE_PYTHON is derived from the list of all available Python slots. >> Excluded are ABIs restricted by an ebuild, say by a line like >> >> RESTRICT_PYTHON_ABIS="3.*" >> >> for software that does not build with Python 3.x. > > I am against this proposal. I already masked python-3* on my system, because > no package actually > needs it, but the current behaviour installs completly useless code for those > versions. Does it? I assume when you say you masked it you also mean that you don't have Python 3.x installed? Packages are installed against an ABI iff: 1) The ABI is know to the python eclass - granted 2) The build is not restricting the ABI 3) The related version of python is actually installed Let's do this check: Please run this command: # equery f dev-python/pyinotify | fgrep site-packages If you don't have any Python 3.x installed you should see no files for it. > Same would > happen for all other, not active versions of python. See above, please re-check if that happens for you. > One default active version should be enough, if > i want more, i can select and set it. Please elaborate in more detail on that so I'm sure I reply to the comment you actually had in mind. Best, Sebastian
