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