Mike Kazantsev schrieb: > On Sun, 14 Jun 2009 18:03:58 +0200 > Florian Philipp <li...@f_philipp.fastmail.net> wrote: > > ... >> Thanks for your answer but I have to say, this looks like a really >> cumbersome workaround. Wouldn't it be better to make portage and >> python-updater aware of this problem? >> >> The update from python-2.4 to 2.5 was a minor one with only a few >> incompatible packages. What shall happen when we stabilize 3.0? We'll >> run into orders of magnitude more problems than we did till now if we >> keep it as it is! >> >> Do you think I should open a bug for this? > [...] > > Installing every package for each compatible python on system if some > use-flag like "multislot" is enabled (it might also be impossible for > some pkgs, which also sit in share/bin/lib) look better and somewhat > easier - just a eselech switch flip and +x (un)installs. > > I wonder, what do you have in mind? >
I don't know. I'm not a python dev. Therefore I might not understand every aspect of the problem. I thought about something like this: eselect maintains a list of all enabled python slots and a primary one, not just the primary one like now. If nothing else is specified, every program uses this primary python version (just like now). Portage installs or symlinks all files which end up in the site-packages directory in the respective directories for every python slot enabled by eselect. python-updater could be augmented to do the necessary rebuilds when a new version is added or an old one removed from the list.
signature.asc
Description: OpenPGP digital signature
