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

[Brian Harring]

On Sun, Jun 06, 2010 at 01:35:55PM +0000, Domen Koooar wrote:
> 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.

$PACKAGE_MANAGER should not have to use python-updater *period*.  If 
the USE_EXPAND route was taken for desired python versions, mapped 
down to virtual/python:$SLOT, the manager would know automatically of 
the needed python subgraph dependency wise.

Really wish people would stop pointing at python-updater; it's a flat 
out hack that exists only due to info not being exported to the PM.  

~harring