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.0 1.0.4-3 high-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-2 SQLite 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-7 A 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]