On 10/26/23 19:01, Egbert Eich wrote:

Stefan Brüns writes:

...

Hi,

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

On SLE/LEAP 15, "openmpi" always meant OpenMPI 1, while suddenly it has become OpenMPI 4. 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.

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

Ok, I see the problem now. Leap has inherited from earlier versions all outdated openmpi1 packages which were denoted as 'openmpi'. Other than SLE, Leap does not drop any packages, so recycling the term 'openmpi' for the default OpenMPI version causes havoc. So even if we denote the default OpenMPI version for *build* purposes, it should never be be used for package naming and dependencies - here the explicit version should always be specified (or 'openmpi' for OpenMPI v1). @Nicolas, could you look into this?

Cheers, Egbert.

There is no "openmpi" package. There is a "Provides: openmpi- %{version}" for the package that is the current default (right now openmpi4). As stated in my other email, this has been the case for over 4 years ! The right way to build against the default openMPI version is what is done in hpx: - BuildRequires: openmpi-macros-devel - Use %{openmpi_requires} and %{openmpi_devel_requires} in right packages to force a dependency to the right version (not just a libmpi.so.XX one) - %{setup_openmpi} in the %build/%install section to setup the openMPI path/ld_library_path and so on If there are (not _multibuild) packages that do not use these macros, they should be changed to use them. I thought I caught all of them when openmpi1 was renamed in Factory but there may be some non Factory one that I missed and luckily kept working since them. Nicolas