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
