ScientificPython - 2.6-6.fc7.x86_64
File conflict in:
Packages with the same files:
ScientificPython - 2.6-6.fc7.i386
well crap..... the script does reference an arch specific filepath...so it does
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/
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?
The arch-specific Python path also makes the script unsuitable
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
> 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
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.
I can't build for or test x86_64 locally. The conflicts checker works
remotely on repository metadata and rpm headers.
fixed and rebuilt.