Todd Rme writes:
> On Sat, Dec 8, 2018 at 2:53 PM Stefan Brüns
> <stefan.bruens(a)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 . 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
> 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
To unsubscribe, e-mail: opensuse-science+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-science+owner(a)opensuse.org