Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: openmpi - a new MPI implementation https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173719 ------- Additional Comments From jvdias@xxxxxxxxxx 2006-02-16 14:02 EST ------- Perhaps the simplest solution may be to simply ship openmpi in a way that does not clash at all with lam, and that allows users to select use of either alternatives(8), or environment-modules, or home-grown solutions, but that does not depend on the new environment-modules package or use alternatives(8) in the .spec file. For example: the 6 mpi* clashing binaries could be installed as: /usr/bin/om-$bin (eg. /usr/bin/om-mpicc) , The clashing libraries could be installed in /usr/lib/openmpi . These are: libmpi*.so ( clashes with lam RPM ) libopal.so ( clashes with opal RPM - the "Open Phone Abstraction Library"!) Proably it is simpler just to put all openmpi libs in /usr/lib/openmpi . and includes in /usr/include/openmpi. Then links could be created in: /usr/share/openmpi/{bin,lib,include} so that e.g. /usr/share/openmpi/bin/mpicc -> /usr/bin/om-mpicc /usr/share/openmpi/lib/libmpi.so -> /usr/lib/openmpi/mpi.so etc. There are as yet NO man-pages shipped in the openmpi distribution (another reason why openmpi is still of "experimental" status IMHO). Then existing lam users and the existing lam package would be totally unaffected. The openmpi package should also provide pkg-config openmpi.pc files to easily provide the linker library and compiler include options to openmpi using builds . Users could decide to use alternatives ( ie. move the lam clashing executables to /usr/bin/lam-*, and make /usr/bin/mpicc an alternative between /usr/bin/om-mpicc and /usr/bin/lam-mpicc ), or could use environment-modules (set PATH, LD_LIBRARY_PATH to select between /usr/{lib,bin,include} and /usr/share/openmpi/{bin,lib,include} with modules). The environment-modules scripts could actually be shipped in /usr/share/openmpi/environment-modules and used at users' discretion, and we could also ship a script to setup alternatives(8). But the existing lam package could stay the same, and no new packages would be required by the new openmpi package. I think the above is what I'll be aiming for with the Core release, unless there are any objections. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
