On Mittwoch, 2. Januar 2019 22:36:52 CET Egbert Eich wrote:

Stefan Brüns writes:

...

Several programs will end up with implicitly linking to both versions, as libnetcdf and hdf5 use openmpi1 and boost_mpi uses openmpi2. One example is vtk.

This would be a nightmare. As I've stated elsewhere already, I believe it would be better if packages that are used by the 'naive' user - and especially their dependencies - should stay away from using any MPI. I don't see the benefit of MPI if you do not specifically set it up for your task. I will have to look at vtk - tomorrow probably.

The "serial" flavor, both in science and Factory, is ok now. The openmpi(1) flavor is somewhat broken, as the dependency set for both openmpi1 and openmpi2 is imcomplete: Only available as openmpi1: - libnetcdf-openmpi, python3-mpi4py Only available as openmpi2: - boost_mpi So we have to fixup the dependencies first. I have converted vtk to a multibuild package, see https://build.opensuse.org/ package/show/home:StefanBruens:branches:science/vtk [...]

...

Question now, which version to choose?

Apparently, openmpi2 does not work on all architectures (PPC, PPC64BE) [1], and is not supported by some software packages [2].

Are there any drawbacks for using openmpi1 everywhere in TW/Leap 15.x?

Besides the fact that it is unmaintained? We do not provide or support it any more on SLE-15. Right now, openmpi2 is supported there, meaning that all openmpi2 packages on Leap 15(.0) will have the benefit of receiving all the bug fixes we add to SLE.

As openmpi2 is seems to available on all supported platforms (even PPC64BE since 2.1.4, science has 2.1.5), it should be a good default for everything not buildable with multiple flavors - probably only python. For vtk, this would mean adding an openmpi2 flavor to netcdf, and switching mpi4py to openmpi2. Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019