Hi Nicolas, Nicolas Morey writes:
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).
On a Leap 15.4 I get: zypper search openmpi | grep " openmpi " [...] | mpitests-openmpi | MPI Benchmarks and tests for openmpi | package | openmpi | A powerful implementation of MPI | package | openmpi-debuginfo | Debug information for package openmpi | package | openmpi-debugsource | Debug sources for package openmpi
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
Yes, this is true - for the future, but not the past - you cannot change the past. The past is what'son Leap 15.n - anything that was shipped since Leap 15.0. Example (on Leap 15.4): zypper info --requires parallel-netcdf-openmpi-devel [...] Requires : [3] parallel-netcdf-devel-data openmpi-devel libpnetcdf1-openmpi = 1.7.0 Here, you have an unversioned dependency to openmpi-devel.
If there are (not _multibuild) packages that do not use these macros, they should be changed to use them.
For this to happen, you will have to rebuild a considerable portion of the packages you no longer want to deal with. If Leap 15.6 will acquire your packages, you will see a lot of conflicts from these old packages.
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.
Factory may be fine if everything has been rebuilt with your macros. Leap still contains packages that pre-date your fixes. SLE may be Ok because we hopefully do not ship these old packages any more. Cheers, Egbert.