Re: Bug#1064810: transition: mpi-defaults
On Mon, Nov 04, 2024 at 09:29:43AM +0000, Alastair McKinstry wrote:
> Hi
>
>
> On 04/11/2024 09:06, Adrian Bunk wrote:
> > On Mon, Oct 21, 2024 at 07:40:29AM +0200, Paul Gevers wrote:
> > > ...
> > > And looking at the content of libopenmpi3t64, I'm wondering if you're not
> > > violating Policy 8.1 [1] (the names of the files suggest the libraries don't
> > > have the same SONAME):
> > > """
> > > If you have several shared libraries built from the same source tree, you
> > > may lump them all together into a single shared library package provided
> > > that all of their SONAMEs will always change together.
> > > """
> > Funnily that does not even cover the problem at hand,
> > which is dropping of one of the same-SONAME libraries.
> >
> > You are thinking towards splitting libopenmpi into 9 library packages
> > (one package per library).
> >
> > A relevant question would be whether they are independent, or whether
> > mixing libraries from different OpenMPI versions in one binary might
> > break.
> >
> > If I have a test build of openmpi5 (libnames changed to libopenmpi40) from OpenMPI 4 does not work with libmpi from OpenMPI 5,
> > then co-installability is anyway not an option and having them in one
> > package is the easiest solution.
>
> I have a test build of openmpi5 (libnames changed to libopenmpi40) under
> test at the moment to prepare for the libopenmpi40 transition.
>
> All of the SONAMES and ABI/APIs are preserved, except for C++ and Java which
> were not formally standardized I believe. This means that both OpenMPI 4 and
> OpenMPI 5 are shipping identical libraries libmpi.so.40 and so will clash.
> I'd need to investigate further if libmpi_cxx.so would cope working with
> OpenMPI 5+ , but at minimum we would need to ship OpenMPI4 and 5 as separate
> source packages, with a complex arrangement of OpenMPI 4 only shipping
> libmpi_cxx.so, which I'm not sure would work.
Noone wants to ship both versions in a release.
My point/question was whether e.g. mixing libraries from OpenMPI 5 and
OpenMPI 6 in a binary would work.
If OpenMPI is a collection of libraries that are only guaranteed to work
together when everything is the same version, then splitting would not
bring any benefits.
> Longer term, we need to add symbols to OpenMPI to avoid transitions.
Symbols don't avoid transitions.
> Alastair
cu
Adrian
Reply to: