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?
> And not just into /usr/local: On some machines I don't have root
> access, so I put it into my home directory under ~/usr. (Ok, so those
> machines aren't Debian, but I think the same principle applies.)
It's probably even worse on other systems, where you have no chance of
expecting that scripts outside your control have a full path to python
instead of using the /usr/bin/env trick.
> Looking at my /usr/bin, I see (with the command
> file /usr/bin/* | grep script | sed 's/:.*$//' | awk '{ getline a <
> $1; if (a ~ /^#\!/) { print a } close($1) }' | sort
> ) that almost all script files specify the location of the interpreter
Sure. Most scripts do. But we're not talking about most scripts,
we're talking about python scripts, and a large number of those use
/usr/bin/env. Of the 220 python scripts on my system, 202 of them use the
/usr/bin/env trick. This includes scripts in /usr/doc/*/examples and such
[0].
> As for the versioned depends, how else do you want to do it?
See previous messages in the thread.
If you've got a script that works with all python versions out so far,
you say:
Depends: python-base, python-glade
and the dependencies will make sure that whatever version /usr/bin/python
happens to be, and the admin will make sure that whatever python is in
the PATH is similarly sensible.
> Say I
> have a package python2.1-foo, which only supports Python 2.1 (it uses
> list comprehensions, say).
Then you'll need to say:
Depends: python-base (>= 2.1), python-gtk, python-gnumeric
and you won't have to worry when python 2.2 comes out. Alternately (depending
on how exactly this gets handled), you can end up with a dependency like:
Depends: python-base (>= 1.5), python-base (<< 2.1), python-gtk,
python-gnumeric
and your package'll work fine with both python 1.5 and python 2.0,
but will need to be double checked by hand when python 2.2 comes out
to ensure it doesn't break. And if it turns out that it doesn't break,
you can just update the dependencies, and your users don't have to care
about updating all of python to get a bug fix in your package.
> Now, assume it depends on python-gtk and
> python-numeric. It has to depend on *2.1* versions of those packages,
> not 1.5.
It needs those packages installed, but care on the part of the python-gtk
and python-numeric maintainers assures that it doesn't need to list
specific dependencies.
> Updating the #! line in the script would be small potatoes compared to
> checking that the package works correctly with a new version of
> Python.
Eh?
Checking whether a script works with a new version of python seems
generally likely to be unnecessary (already done upstream) or trivial (the
backwards incompatabilities seem to usually be pretty well documented,
and limited to things that won't affect most people).
> > And all this for what, precisely?
> [Your two examples are essential base programs in Debian -- it would
> be stupid to fiddle with them, unless you know what you're doing]
*shrug* It's stupid to fiddle with anything that's part of your system
unless you know what you're doing. If you put a messed up perl in
/usr/local/bin, you'll break shell one liners that invoke "perl" without
a full path and expect it to work as perl. If you put a messed up KDE
install in /usr/local, you'll end up not being able to build some KDE
apps properly. Big deal. There's an obvious solution: don't put messed
up programs in /usr/local; or, if you must, at least call them something
completely different.
> I see it as: this package I installed worked, and I don't care whether
> it's written in python or perl or tcl... Now, I've compiled my own
> python, and the package doesn't work anymore!
And *gosh*, all I have to do to fix it is either (a) add the batteries,
or (b) mv /usr/local/bin/python /usr/local/bin/python212opt.
> I see no reason why
> scripts shouldn't specify exactly which interpreter they expect to be
> using.
Please reread the message you just replied to then.
Cheers,
aj
[0] dpkg --get-selections | grep python | sed 's/[[:space:]].*$//' |
xargs dpkg -L | sort -u | xargs echo |
while read a; do
find $a -type f -maxdepth 0 -printf "%p: " -exec head -n 1 {} \; ;
done | grep -a '^[^:]*: #!.*python'
--
Anthony Towns <aj@humbug.org.au> <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
Attachment:
pgps_6tB2CcvH.pgp
Description: PGP signature