At some point, Anthony Towns <aj@azure.humbug.org.au> wrote:
> On Mon, Oct 22, 2001 at 08:32:33AM -0700, Neil Schemenauer wrote:
> > Anthony Towns wrote:
> > > On Mon, Oct 22, 2001 at 10:13:17AM +0200, Gregor Hoffleit wrote:
> > > > Say, you would install 2.1.2 in /usr/local.
> > > How about we just say "Don't install other versions of python in
> > > /usr/local" ?
> > Please no. Making this work properly is not hard.
>
> 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. My reasons are two-fold: I like experimenting
with the latest, greatest, bleeding-edge python, and I also want to
compile it with optimizations (which can give me a small speedup;
important for the numerical work I do).
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.)
> 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*
> python executables need to be modified at the source level for every
> python upgrade, and finally it makes Debian veer away from upstream
> standards for python scripts.
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
-- the only exceptions being some python scripts and one perl script
(all of the other perl scripts do some variant of #!/usr/bin/perl).
So, I don't think it's too much to ask that scripts that Debian
installs specify the location of the interpreter.
As for the versioned depends, how else do you want to do it? Say I
have a package python2.1-foo, which only supports Python 2.1 (it uses
list comprehensions, say). Now, assume it depends on python-gtk and
python-numeric. It has to depend on *2.1* versions of those packages,
not 1.5. This has nothing to do with the scripts in python2.1-foo
having to use #!/usr/bin/python2.1. (I use 2.1 here instead of 1.5 as
I believe there is little to prevent one from making a 1.5 package use
2.1 -- however, going to 2.2 would be more difficult).
Updating the #! line in the script would be small potatoes compared to
checking that the package works correctly with a new version of
Python.
> And all this for what, precisely?
>
> If you install new versions of standard tools in /usr/local you have
> to be careful. This applies to a hypothetical /usr/local/bin/dpkg, or
> a /usr/local/bin/sed, or whatever. Going out of your way to make sure
> it doesn't apply to a /usr/local/bin/python seems to this observer a
> complete waste of time.
[Your two examples are essential base programs in Debian -- it would
be stupid to fiddle with them, unless you know what you're doing]
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! I see no reason why
scripts shouldn't specify exactly which interpreter they expect to be
using.
--
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke
|[EMAIL PROTECTED]
