On Tue, Oct 23, 2001 at 10:59:45PM +1000, Donovan Baarda wrote: > > Again, _why_ does this matter? Who does this? Is it even remotely common? > > That people would even consider installing another version of python in > > /usr/local surely just points to a problem with the Debian packaging, no? > The most common reason for installing python in /usr/local is to play with > the latest and greatest bleeding edge.
In which case you probably don't really care if you have to type "python2.2"
at the prompt instead of just "python".
> I know that you can rename the executable to something else, but
> what does a basic "make install" do?
"make altinstall" looks like it would do the right thing, unless you're
being really obsessive in which case you might need "make altinstall
VERSION=211opt" or something similarly whacky.
> > The problems with using "#!/usr/bin/python1.5" is threefold: first, it
> > makes dependencies that much more complicated: *all* python scripts have
> > to depend on versioned modules in every way, ie "Depends: python1.5-base,
> > python1.5-glade, python1.5-gtk, python1.5-numeric", second it means *all*
> How else are you going to ensure that a script that relies on version
> 1.5 of python runs using that version, when you also have python2.1-base
> installed,
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.
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".
> ie, leave it up to the package mantainers, but make them aware of the pro's
> and con's.
Which afaics concludes it as:
Use /usr/bin/python or /usr/bin/env python generally, with
dependencies of the form "python-base (>= <X>.<Y>), python-base
(<< <Z>.<W+1>)" where X.Y is the earliest version of python that's
okay (can be omitted for X.Y = 1.5), and Z.W is the latest version
known to work. (Not having the Z.W+1 dep could be cause for a
wishlist bug if Z.W+1 hasn't been released even in alpha/beta
from upstream; a normal bug if it's been released upstream,
and a serious bug if it's been released in Debian, perhaps)
Use /usr/bin/pythonX.Y with a dependency on "pythonX.Y-base"
if you wish to use a particular version of the interpretor
independent of whichever version may be default. Useful only
for legacy apps that can't be upgraded to the current version,
and apps that depend on features in unreleased versions of python.
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.
Now, for the wild and whacky python freaks out there this won't be enough.
Some of y'all will want to keep 1.5 around for the kludgy old app you
use that uses a couple of undocumented tricks and that no one understands
enough to port to 2.0. Others will want to use some 2.1 packages you've
snarfed off a website, but only for your own scripts because you couldn't
be bothered keeping all the other random modules in sync too. Others
will want to beta test 2.2 by doing a CVS checkout and building it
in /usr/local.
Does that sound accurate? Is there a use-case that's interestingly
different to the above?
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.
Making sweeping policy requiring lots of scripts to be modified, either
from how they are in the archive now, or on a regular basis, to avoid
the above, seems silly to me.
Cheers,
aj
--
Anthony Towns <[EMAIL PROTECTED]> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
"Security here. Yes, maam. Yes. Groucho glasses. Yes, we're on it.
C'mon, guys. Somebody gave an aardvark a nose-cut: somebody who
can't deal with deconstructionist humor. Code Blue."
-- Mike Hoye,
see http://azure.humbug.org.au/~aj/armadillos.txt
pgpsndhuaCv2m.pgp
Description: PGP signature
