Disclaimer: I don't know much about python. I just want to make sure that you're not making the same mistakes that were made when perl was modified so multiple versions could be installed at one time.
> . Python 1.5 was installed and we decide to install 2.0 > python 1.5 specific packages are installed in > ...python/1.5/site-packages > other packages are installed in ...python/site-packages > > * we make /usr/bin/python point to python 2 thanks to alternatives This is where I begin getting flashbacks to the whole perl SNAFU. Is it possible for a python program to use python 2.0 features and not work with 1.5? Is it possible for a program to use deprecated 1.5 things and not work with 2.0? Is it possible some later version of python after 2.0 will introduce new features programs could use? All of these things were true with perl, and all of them tripped us up horribly. The problem is, if you have two versions of perl (or python) installed and /usr/bin/perl(python) is managed with alternatives, dependancies are useless. A package that uses perl 5.6 (ptyhon 2.0) features should depend on that package. But a user can install an older version still, and can modifiy the alternatives to make it the default, and then the program breaks, even though its alternatives are satisfied. The only way to make a program that uses perl 5.6 (I'll stop putting the equivilant ptyhon stuff in parens now :-) reliably work is to make it use #!/usr/bin/perl-5.6. But this is just shooting yourself in the foot when perl 5.7 comes out and your package works with it fine except it refuses to use it because the filename is different. It's a horrific can of worms, which is why perl in debian is no longer going to do this at all -- it's just not worth it. I encourage you python folks to think this through before adopting a similar scheme. Good luck! -- see shy jo
