[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: What should we do now?



On Wed, Oct 24, 2001 at 01:42:12AM +1000, Anthony Towns wrote:
> On Tue, Oct 23, 2001 at 10:59:45PM +1000, Donovan Baarda wrote:
[...]
> Uh, how many scripts rely on python 1.5? If Debian's main python is 2.1,
> why should a python 1.5 script remain available? I can't see any reason
> for this, and I can't see any reason why it would even happen.

Perhaps you should read back through the archives at this point... this has
all been discussed already... and dare I say we already have a solution...

> The obvious answer, anyway, is that you simply don't get to install
> python 2.1 as /usr/bin/python while you have that script on your system,
> due to its dependency on "python-base << 2.1".
[...]

There are many _big_ applications which are tied to particular versions of
Python and upgrade at different rates to Python. Zope, mailman, etc. These
big apps would either end up including their own Python, holding back the
Debian Python, or would just not exist as debs under a "single Python"
scheme.

One of the main objectives of the slowly gelling policy has been to support
multiple versions of Python installed at once, while still allowing
applications that are not tied to a particular version to use more a general
"Depends: python-base (>=1.5), python-base (<<2.2)" and "#!/usr/bin/python"
(or "#!/usr/bin/env python") without tying themselves up.

> To step back a bit, the idea is that for any Debian release we should
> have a single main version of python. For woody, that'll probably be,
> well, let's assume 2.0, and that for the next release it'll probably be
> 2.1 or 2.2. And so on.  All packages that use python will be expected to
> use whichever version that is. Most people (including myself) shouldn't
> have to give a damn beyond this.
[...]

Yep, that's the plan. We implement it with multiple pythonX.Y-base packages,
and then the python-base (X.Y-Z) package makes one of these the default by
providing a symlink /usr/bin/python to /usr/bin/pythonX.Y.

> What I'm trying to say is that the important case to consider, the one
> to make as easy and efficient, and effective and reliable as possible is
> the first one, not the second. Admins who need an old version of python
> can cope with changing the top line in the few scripts where it matters
> from /usr/bin/env python to /usr/bin/pythonX.Y. Python hackers trying
> to keep up with the van Rossums ought to be able to manage to use the
> "altinstall" target without breaking a sweat.

There is more to this than just "#!/usr/bin/pythonX.Y". Where do packages
install their python modules? Do they use /usr/lib/python2.1 because 2.1 is
the default? What happens when 2.2 becomes the default?

Read the archives for a solution :-)

-- 
----------------------------------------------------------------------
ABO: finger abo@minkirri.apana.org.au for more info, including pgp key
----------------------------------------------------------------------



Reply to: