More random thoughts...
How many versions of Python do we really need to support at one time?
Zope and Mailman both need Python 1.5.2 (and depend on python-base >=
1.5.2-x, BTW), but don't need any extra packages like mxDateTime.
If there are any other packages that don't work with Python 2.1, do
they need extra extensions themselves?
It seems to me that each stable release of Debian will only need to
support a maximum of two different versions of (C)Python, both of
which will be quite different. All extra Python modules just have to
be compiled against the latest package, and the version of Python from
the last Debian release can be removed.
For example, woody will have Python 1.5.2 and 2.1.1 when it's
released. By the following release of Debian, 2.2 or even 2.3 will be
current. Will there be any packages that need 2.1.1 by then?
I think I was trying to make a point here:
Especially while the freeze is beginning for woody, there's no time
to design, implement, test and deploy any scheme for sharing module
source, etc., or for doing really fancy dependencies.
Instead we should ensure that there is a smooth upgrade path from
potato to woody, and that future improvements for woody+0.1 are not
ruled out.
So...
Python 1.5.2, in package "python-1.5", installs modules in
/usr/lib/python1.5/, installs the binary in /usr/bin/python1.5 and
uses alternatives for /usr/bin/python. It conflicts with
python-base.
Zope and Mailman are recompiled with dependencies on "python-1.5"
(no versioned depends).
Python 2.1.1, in package "python-2.1", installs modules in
/usr/lib/python2.1/, installs the binary in /usr/bin/python2.1, and
uses alternatives, with a higher priority than python-1.5.
python-2.1 conflicts with python-base, too.
All other packages providing Python modules or using libpython, are
recompiled against 2.1.1, with an unversioned dependency on
"python-2.1".
"python-base" is removed from the archive.
Virtual package "python" turns into a real but empty package, that
depends on "python-2.1". Scripts written in Python may depend on
"python", but may expect bug reports later when they turn out to be
incompatible with a new version of Python. (Or an old version via
alternatives. They should probably just depend on "python-2.1"
themselves.)
Debian packages that have scripts written in Python should use one
of "/usr/bin/pythonx.y" or "/usr/bin/env pythonx.y" if they depend
on "python-x.y". They should use "/usr/bin/python" or "/usr/bin/env
python" if they depend on "python".
I have no idea whether /usr/bin/env python or /usr/bin/python is
better. /usr/bin/env means that another version of Python can be
installed in /usr/local, and scripts using env will start using it.
Whether this is good or bad for a Debian package is another question.
...
Wow. That got a bit longer than I anticipated. If anyone got down to
here, do you have any comments? I can expand on my reasoning if it
would help.
Thanks.
--
Carey Evans http://home.clear.net.nz/pages/c.evans/
"Quiet, you'll miss the humorous conclusion."
