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
signature.asc
Description: OpenPGP digital signature
