(Resending to the list as I has a subscription issue) Hi, On 10/26/23 18:15, Stefan Brüns wrote:

Hi,

the recent removal of OpenMPI 1/2/3 from the science project has broken the ABI.

It has not been removed just yet. Just disabled from the various _multibuild files. SR have been sent to all (if some are missing let me know) packages that still used openmpi[123] in Factory. The SR to drop them from Factory is waiting for all these packages changes to make it into Factory first.

On SLE/LEAP 15, "openmpi" always meant OpenMPI 1,

It hasn't for the last 4 years ! https://build.opensuse.org/package/revisions/science:HPC/openmpi1 We used to have openmpi and then openmpi[23..] came along. 4 years ago the openmpi was renamed to openmpi1 to clean this up and all the packages were tuned/tweaked accordingly. There has been 2 use case since then: - Either you needed "an" openMPI and you are supposed to use openmpi-macros-devel which gives you a set of macro to use the current OpenMPI release. https://build.opensuse.org/package/show/science:HPC/hpx is a good example of using the macros. - You need to build against multiple flavors for the HPC module or similar requirements. In that case, multibuild with specific ties to openmpiX had to be set. https://build.opensuse.org/package/show/science:HPC/imb for example If you look at both those project dependencies, they do not simply depends on the libmpi.so which would break all stuff but have dependency to the proper openmpiX-libs or libopenmpiX-gnu-hpc package instead. Same for devel packages.

while suddenly it has become OpenMPI 4.

The switch from openmpi1 to openmpi2 as default was made over 4 years ago: https://build.opensuse.org/package/rdiff/science:HPC/openmpi2?linkrev=base&rev=98 The one from openmpi2 to openmpi4 was 2 years ago: https://build.opensuse.org/package/rdiff/science:HPC/openmpi4?linkrev=base&rev=16 I would not call that sudden :) As a reminder, the dropped versions have been obsolete for a while - openmpi 1.10.7 was released May 2017 - openmpi 2.1.6 was released Nov 2018 - openmpi 3.1.6 was released Mar 2020 Those packages are old, and not getting anymore support from upstream!

Anyone using packages from the science project will end up with packages which are linked to either openmpi1 or openmpi4, and an application may pull in both at the same time - obviously not a good idea.

For packages already be using the "default" openMPI (v4), the drop should be seamless as dependencies are tied to the proper MPI version and update paths are handled. For "multibuild" packages, it simply means they won't be updated anymore unless the user switches to a flavor that is still supported.

So, can this please be fixed ASAP, before too many users are hit by this?

Unless I'm missing something, there should not be any issue. Can you point me to a specific use-case/package that breaks? Nicolas