I see now that the python2 packages made it into unstable. This is a
mistake IMHO. The Perl guys tryed this and it didn't work. Also, the
name should have been python2.1 not python2. What problem does naming
the packages "python2" solve? It seems like a big pain for everyone
for no gain.
I've updated my set of experimental packages. They are available at:
http://people.debian.org/~nas/woody/
There are three source packages:
python_2.2.1
python-1.5_1.5.1
zope-2.3_2.3.3
These create the following binary packages:
python_2.1.1
python-dev_2.1.1
python-elisp_2.1.1
python-examples_2.1.1
python-gdbm_2.1.1
python-mpz_2.1.1
python-regrtest_2.1.1
python-tk_2.1.1
python-xmlbase_2.1.1
idle-python_2.1.1
python-1.5-dev_1.5.2
python-1.5_1.5.2
zope-2.3_2.3.3
The zope-2.3 package depends on python-1.5. The python-base package is
gone. I've changed sys.path to:
['',
'/usr/local/lib/site-python',
'/usr/local/lib/python2.1/site-packages',
'/usr/lib/python2.1/site-packages',
'/usr/lib/python2.1',
'/usr/lib/python2.1/plat-linux2',
'/usr/lib/python2.1/lib-tk',
'/usr/lib/python2.1/lib-dynload']
as per Jérôme Marant's request. I think the only major problem left to
solve is fixing packages with broken dependencies. Using Gregor's
terminology I think that the policy should be:
Python modules and Python embeding apps should depend on
"python (>=X.Y), python (<<X.Y+1)". They should install themselves
into /usr/lib/pythonX.Y/site-packages.
Python programs should depend on "python" or "python (>=X.Y)". They
should not install any modules in the standard Python path.
I'm willing to build new version of packages with broken dependencies.
Can we handle the upgrade from Python by having a long list of conflicts
in the "python" package? Something like:
Conflicts: python-some-extension (<< X.Y), ...
Please advise. I'm very determined to get Python 2.1.1 into woody and
am willing to put in a lot of work to make it happen.
Neil
