Todd Rme writes:

On Sat, Dec 8, 2018 at 2:53 PM Stefan Brüns <stefan.bruens@rwth-aachen.de> wrote:

...

No matter what we pick, I think it would be a good idea to do what we do with, say, gcc and llvm/clang, where we have separate "openmpi1", "openmpi2", and "openmpi3" packages, and have the "openmpi" package refer to the default version. This would make it easy to change default versions in the future, or set default versions on a per-architecture basis.

Can we ensure that once the (build)-dependency of the dummy 'openmpi' changes that all the packages that require it will be rebuilt?

As for openmpi 1 vs openmpi 2, the problem with openmpi 1 is that it is unmaintained [1]. The current version of openmpi is actually version 4. So using it openmpi 2 as the default comes with all the problems associated with unmaintained software, especially network-oriented software. openmpi 2 also adds support for MPI 3.x features.

Yes.

openmpi 2 is supposed to support PPC. If it doesn't that is probably a bug that should be reported upstream. Unfortunately the linked request doesn't explain what the problem is.

I guess I can try and ask Andreas, the problem is that PPC and PPC64 are fringe platforms that very few people have access to or care about. At SUSE we do support openmpi2 on PPC64le on the enterprise product, but this platform is a totally different ballgame. Thus people from the PPC(64)be community would have to step in here and help. Cheers, Egbert. -- To unsubscribe, e-mail: opensuse-science+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-science+owner@opensuse.org