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.
On 10/26/23 22:10, Egbert Eich wrote:
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
Agreed.
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.
OK. But in that case, it may have already been broken depending when it was last rebuilt. In Leap 15.0, openmpi = openmpi1 In Leap 15.1, openmpi = openmpi1 from 15.0 as the new "default" macros/Provides were not yet used In Leap 15.[234], openmpi = openmpi2 through a Provides: In Leap 15.5, openmpi = openmpi4 So depending on where the package is inherited from, they might already be broken! I agree it's messy and as you said, we can't change the past (although if absolutely necessary, we could trigger rebuild for broken packages in Leap updates). But the original complaint was regarding the drop from the science project which makes it completely different IIUC. 1) It should have 0 impact on Leap 2) science doesn't inherit package from older stuff so there should be no ancient leftovers 3) In theory, all the science packages are either _multibuild or using the new macros (if not, they should be) and it should just work. There might need to be some precautions to take when we switch to openmpi5 as the new default in the next year or so, but none of the current changes should have any impact, apart from deleting packages
participants (2)
-
Egbert Eich -
Nicolas Morey