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
pgpMvsX368M74.pgp
Description: PGP signature
