Re: [gentoo-dev] Actions of python team, especially Arfrever wrt python eclass and python-3*

[Thomas Sachau]

Am 06.06.2010 15:35, schrieb Domen Kožar:
> On Sun, 2010-06-06 at 14:41 +0200, Thomas Sachau wrote:
>> Am 06.06.2010 13:50, schrieb Domen Kožar:
>>>> And if you add a python slot or remove one, portage currently is not able to see that and to
>>>> reinstall packages, which had modules installed for that slot. You need another tool
>>>> (python-updater) to check that and to call the needed reinstalls.
>>>
>>> I agree with this fact, user should not be required to read additional
>>> documenation for portage to function as wanted.
>>>
>>> I'm very unfamiliar with inner workings of portage, but using
>>> python-updater implementation, USE_PYTHON behaviour shouldn't be that
>>> hard to implement?
>>
>> You want some additional switch to portage, which does the work of python-updater? That would just
>> move the code, but would still have the same limitations. What does speak against explicit user
>> control for optional features/slots, including dependency handling by the package manager like in my
>> proposal?
>>
>
> Maybe I expressed myself wrong. Portage would only reuse python-updater
> to detect and repair changes with python installation.
>
> If I understand correctly, one solution would be to pull stable 2.x, and
> only install other slots according to USE_PYTHON.
>

And how would that improve the current implementation?

If you only reuse python-updater code inside portage, the issues of the current implementation still
remain. And you dont seem to answer my question.

Why dont you want to allow the user to control *per package*, for which slots it should be installed?
And why dont you want to allow the package manager to mangle the dependency part with already
existing code ( USE flags and --newuse, dependency tree and --depclean)?


-- 
Thomas Sachau

Gentoo Linux Developer