* Anthony Towns <aj@azure.humbug.org.au> [011023 09:07]:
> On Tue, Oct 23, 2001 at 01:31:50AM -0400, David M. Cooke wrote:
> > At some point, Anthony Towns <aj@azure.humbug.org.au> 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?
> > Well, I do it for one.
>
> And is there some reason you can't call them /usr/local/python2.1-opt, say?
>
> Or is there some reason you can't just install all the modules you otherwise
> have installed?
Just to make the discussion a little bit more focussed: I think several
issues were mixed up in my original mail:
(1) For once, #!/usr/bin/env has it's problems. Scripts that use
"#!/usr/bin/env python" are more fragile than scripts without.
(2) Another issue is "python" vs. "python1.5". It's a separate question
whether scripts need to be strictly coupled to a specific Python
version.
Regarding (1): If you ask me how common the situation is that people
install local Python versions in /usr/local, then I will ask you how
common it is that it's reasonable that a script provided by a Debian
package will benefit from using #!/usr/bin/env ?
Regarding (2): Making the dependency explicit (by using
/usr/bin/python1.5) is just playing safe.
As far as I can see, if we hadn't the legacy of the existing packages
and installations, and if versioned dependencies would work on all
systems in all situations, we could come up with a quite clean setup:
python-base et al. could be empty packages (virtual packages wouldn't
work!), and other packages could depend on them (e.g. "Depends:
"python-base (>= 2.0), python-gtk" for a package that need at least
Python 2.0 or better. Still in this case, what could you do if Python
2.3 broke that script ?)
But we haven't an ideal situation, so we have to fight with that kind of
legacy.
But maybe it brings us to the core of the problem:
As far as I can tell our principal problem is that there's a large set
of existing packages (from slink, potato) that have wrong dependencies
(like unversioned "Depends: python-base" for packages that depend on
Python 1.5.2) that would be (erronously) satisfied if we just continued
to use python-base and so on.
One way to resolve this is to include a huge list of conflicts in
python-base et al.
Another way to resolve this is to drop these package names, perhaps in
favour of some other package names.
IMHO, in the current, messed up situation, scripts and packages that
play safe in explicitely stating a Python version have the big advantage
that they will lead to these kinds of problems with underspecified
dependencies.
It's much the same reasoning why libraries have a number in them that
will be increased for incompatible API changes. AFAICS, with the setup
you are suggesting you can never warranty that kind of robustness.
Gregor
