ScientificPython - 2.6-6.fc7.x86_64 Conflicts: 1 File conflict in: /usr/share/doc/ScientificPython-2.6/impipython.sh Packages with the same files: ScientificPython - 2.6-6.fc7.i386
well crap..... the script does reference an arch specific filepath...so it does conflict. Any suggestions on how to make these not conflict? the offending script line is: mpirun -np 2 /usr/bin/mpipython /usr/lib/python2.4/site-packages/Scientific/BSP/ Console.py Is there an obvious way using environment variables to replace /usr/lib/ in that filepath so its generally correct for all arches? Should I rename the file on a per arch basis? -jef
The arch-specific Python path also makes the script unsuitable for /usr/share. But it could be made arch-independent similar to this: mpirun -np 2 /usr/bin/mpipython `python -c "from distutils.sysconfig import get_python_lib; print get_python_lib(1)+'/Scientific/BSP/console.py'"`
(In reply to comment #2) > The arch-specific Python path also makes the script unsuitable > for /usr/share. Even shipped as a doc? its provided more as a courtesy, than as a functional script. > > But it could be made arch-independent similar to this: > > mpirun -np 2 /usr/bin/mpipython `python -c "from distutils.sysconfig import > get_python_lib; print get_python_lib(1)+'/Scientific/BSP/console.py'"` This its great! I'll integrate this fix, and roll up some locally built rpms tonite. Can you test them and report back to make sure the multi-lib issues are dead. FYI, I just got a 64bit system locally, but its running 32bit fedora at the moment. I need to establish a 64bit install in a chroot so I can finally do my own pre-buildsystem push testing to catch multi-lib issues. Personal work-units are in short supply. Thanks again for the alternative script. -jef
I can't build for or test x86_64 locally. The conflicts checker works remotely on repository metadata and rpm headers.
fixed and rebuilt.