python2.1 et al.
It's been much too long since I posted the last status report. I'm
swamped with all kinds of real world work, and wasn't really able to
keep up in time with the discussion.
Reading the discussion, I thought that in order to consolidate a Python
policy, it might help to collect the information in a Wiki. I tried to
setup a ZWiki, and started to fill in a few statements. You can enter
the ZWiki from this URL:
http://people.debian.org/~flight/python/policy/
Up to now, that Wiki lacks memberships functions, i.e. you can only post
anonymously. If somebody gives me a quick tutorial how to add membership
functions to a ZWiki site in ten minutes, I'll do that. Until then,
please include your name in all comments.
If you're not used to Wiki sites, feel free to look at
http://dev.zope.org/. They are using wikis for all discussions about
Zope development. The ZWiki site, zwiki.org, seems to be down at the
moment.
Regarding the packaging: I'm working on the 2.1.1 packages. I'm
currently changing the build environment in debian/, so that templates
are used for most control files. That makes it very easy to package
stuff under names as python2.1-base etc., and still, with one change in
debian/rules, the packages build as python-base etc.
That's an very necessary step to make maintenance of multiple Python
versions easier.
A snapshot of Python 2.1.1 (python2.1-*) and Python 1.5.2 builds
(python1.5-*) using the new system can be previewed in
http://people.debian.org/~flight/python/snapshot/
The 2.1.1 packages in fact are already installable; the 1.5.2 packages
don't install, since the dependencies are not yet set up in order to
make an upgrade from the python 1.5.2 packages. Still, all packages are
buggy (2.1.1 fails five regrtests!), and only intended as preview.
Since time is now very pressing (yes, I know, that's my fault), I'm
afraid we won't be able to make the big jump to a halfway perfect
solution for all the discussed problems.
>From the discussion, the most pressing problem is how we tackle the
upgrade of potato python-* packages, especially when they have
incomplete/incorrect dependencies.
While I still think it's necessary that we find a solution how a Python
extension package can install and register itself for a variety of
different Python versions, I haven't seen a solution that's clean and
obvious, easy and robust to implement and that's something we won't
regret in a few months.
My proposal for woody: Python 1.5.2 is renamed to python1.5-*. Python
2.1.1 will be shipped as python2.1-*. Do we need python2.0-* as well ?
Then, we still have to agree on a strategy how to set up the
dependencies, in order to make the upgrade work in an intuitive way.
For maintainers of Python extension modules, this would mean that they
would have to build one package for each included Python version, e.g.
python1.5-mysqldb, python2.0-mysqldb and python2.1-mysqldb.
There would be no python-* packages in woody!!!
With that setup, we could use our existing, well-tested system, and
still would resolve a few critical problems that we're currently facing
due to the ambigous package names python-*.
In a later future, I'd like to set up a robust system that makes it
possible to provide python-* packages that work for all installed Python
versions. Maybe like the emacsen system.
Gregor
Reply to: