Package: python2.5
Version: 2.5.1-7
Severity: normal
File: distutils
This is a bug which is triggered under somewhat nonstandard, but not
weird conditions. It involves having a python package with a setup.py
file in a filesystem that is accessible from two different machines.
The package contains a script.
In my case, machine A is a i686, and machine B is a x86_64.
The package is to be installed on both computers. The two
computers have PYTHONPATH and the file system set up correctly so that they
don't share executables or libraries.
Now, I move into the directory as seen from machine B
and run
python setup.py install --prefix=somewhere/good/for/B
Distutils copies the script into .../build/scripts-2.5/show_model
and modifies the first line to refer to the correct interpreter:
/home/gpk/bin/Linuxx86_64/python.It then copies *that* into
somewhere/good/for/B. All is fine so far.
Now comes the trouble. I move into the directory as seen
from machine A and run
python setup.py install --prefix=somewhere/good/for/A
It sees that there is a script in .../build/scripts-2.5/show_model
and copies it into somewhere/good/for/A.
*HOWEVER* that script is no longer machine-independent. Its first
line refers to a 64-bit python that is not available on machine A.
Thus, when I run the script on machine A (the 32-bit one) I get this:
bash: /home/mint/gpk/local/bin/show_model: /users/gpk/bin/Linuxx86_64/python:
bad interpreter: No such file or directory
This is a bug.Scripts that have been modified (i.e. specialized
for a particular machine) should not be shared.
There is obviously some intent to make setup.py work in situations like this.
For instance libraries are tagged with the architecture and python version:
e.g. copying build/lib.linux-i686-2.5/newstem2/problem_def.py -
/home/mint/gpk/local/lib/python2.5/site-packages/newstem2
The bug is the assumption that the scripts are still architecture-independent
after
they are tagged to use a particular python interpreter.
Note that this won't trigger with two bog-standard Debian installations because
both would have their pythons in /usr/lib/python2.5 .However, it triggers as
soon as anyone tries to compile their own python, because then you can get
the interpreters on the two machines having different pathnames.
Presumably, it could also happen if one machine ran Debian Stable and the
other ran testing.The two versions could have different versions of python
as their default.
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.22-3-686 (SMP w/1 CPU core)
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash
Versions of packages python2.5 depends on:
ii libbz2-1.01.0.4-3high-quality block-sorting file co
ii libc6 2.7-6 GNU C Library: Shared libraries
ii libdb4.5 4.5.20-11 Berkeley v4.5 Database Libraries [
ii libncursesw5 5.6+20080203-1 Shared libraries for terminal hand
ii libreadline5 5.2-3 GNU readline and history libraries
ii libsqlite3-0 3.4.2-2SQLite 3 shared library
ii libssl0.9.8 0.9.8g-4 SSL shared libraries
ii mime-support 3.40-1.1 MIME files 'mime.types' 'mailcap
ii python2.5-minimal 2.5.1-7A minimal subset of the Python lan
python2.5 recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
