Here's my two cents. It might be a bit rambling, given how late it is here...
[...] > "Barry A. Warsaw" <[EMAIL PROTECTED]>: > > Yes, definitely as both a Zope and Mailman developer <wink> I need > > multiple Python versions. But I suspect even normal users of the > > system will need multiple versions. Different Python-based apps are > > requiring their users to upgrade Python on their own schedule, so > > multiple versions will still be required. For the big applications like Zope and Mailman, how much is required in the way of non-core packages? It would be considerably easier if the only versioned Python packages were those compiled from the distribution tarball, and extra packages like python-gnome were only required to be packaged for the latest Python version in time for each Debian release. [...] > Thomas Wouters <[EMAIL PROTECTED]>: > > None are compatible. This might change, but I don't think so -- I > > think the CVS tree already has a different bytecode magic than 2.1, > > though I haven't checked. Perhaps what Gregor wants is a set of > > symlinks in each python version's site-packages directory, to a > > system-wide one, and a 'register-python-version' script like the > > emacs/xemacs stuff has that adds those symlinks. That way, the > > .pyc/.pyo versions would remain in the version-specific directory. This seems like a reasonable idea, for code that works with all available Python versions. There's no need to change the Python interpreter to look in different places, or even to change compileall.py. The registration/update script could be in a "python-common" package that each of the different Python version packages depend on. [...] Gregor Hoffleit: > We should look at the perl packages (they support concurrent versions) > and a Emacsen (they have a system for registration of .el files that can > be byte-compiled at installation time, and they support this for > concurent and different Emacsen flavors). *Does* Perl support concurrent versions? All I seem to have available from the mirrors is 5.6.1. Thinking about the transition, it seems to me that relying on all the Python packages to change their dependencies on python-base is going to be hard to get right. It would still be possible to use apt-get to install a new version of python-base, and existing packages that only depend on ">= 1.5.2" won't be automatically upgraded. Perhaps python-base should be removed in favour of Python package names that include the first and second version number components, something like the perl-api-x.y packages. ("python-base-2.1" or just "python-2.1"?) The "python" package could be something like the "gcc" package - mostly just an indication of the default version from the user's point of view, and something to make sure the latest version is available after a dist-upgrade. Though that leaves the problem of the packages currently depending on "python"... If it's any consolation while you're trying to work out a plan, just be glad Python isn't "Essential: yes" like parts of Perl. -- Carey Evans http://home.clear.net.nz/pages/c.evans/ "Quiet, you'll miss the humorous conclusion."