Re: Status report on python2 transition
Here's my two cents. It might be a bit rambling, given how late it is
here...
[...]
> "Barry A. Warsaw" <barry@digicool.com>:
> > 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 <thomas@xs4all.net>:
> > 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."
Reply to: