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.
