Processed: transition: mpi-defaults

Package: release.debian.org
Severity: normal
Usertags: transition
Control: affects -1 + src:mpi-defaults
OpenMPI 5.0 drops 32-bit support, so we need to move those archs to
MPICH.
notes =
"https://lists.debian.org/debian-release/2023/11/msg00379.html";

Be mindful that Ubuntu is about to freeze for their noble LTS release.
We're (or I'm) still updating some Debian packages with the hope to get
the new versions (and new packages) into noble. Since it's an LTS
release, our packages will still be supporting their users in, say, 3 or
4 years time.

Would it be reasonable to pause the 32-bit mpich transition until after
they've frozen noble?
Or alternatively, can this mpich transition be completed in time to make
it into their freeze (only days left).

Drew

Alastair McKinstry

2024-02-26 12:30:01 UTC

Post by Drew Parsons

Package: release.debian.org
Severity: normal
Usertags: transition
Control: affects -1 + src:mpi-defaults
OpenMPI 5.0 drops 32-bit support, so we need to move those archs to
MPICH.
notes = "https://lists.debian.org/debian-release/2023/11/msg00379.html";

Be mindful that Ubuntu is about to freeze for their noble LTS release.
We're (or I'm) still updating some Debian packages with the hope to
get the new versions (and new packages) into noble. Since it's an LTS
release, our packages will still be supporting their users in, say, 3
or 4 years time.
Would it be reasonable to pause the 32-bit mpich transition until
after they've frozen noble?
Or alternatively, can this mpich transition be completed in time to
make it into their freeze (only days left).
Drew

Hi

I think we can get mpich 4.2.0 into noble. I've been doing a full
rebuild of mpich repds and mpich4.2 is not a transition (as feared);
I'll do an upload later today. This is independent of mpi-defaults.
I'm test-building mpich on armhf and hopefully will have a test
completed today/tomorrow.

Regards

Alastair

Alastair

--
Alastair McKinstry,
GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5
e: ***@debian.org, im: @alastair:mckinstry.ie

Alastair McKinstry

2024-04-06 07:50:04 UTC

OpenMPI 5 drops 32-bit support, but otherwise does not change the API/ABI.
So it is technically not a transition, but breaks 32-bit builds.

Doesn't make it better. This is not the time to do that without tests
builds and bugs filed.

The solution is changing mpi-defaults to MPICH for 32-bit archs. MPICH
builds on all archs, but testing all dependencies of the change has not been
tested, and I don't know how you would do that - setting up eg ratt to
rebuild all on 32-bit archs (as everything on 64-bit will not have changed.)

Beside the easy part of chaning mpi-defaults, I count 30 something
packages that have explicit build dependencies on libopenmpi-dev. None
of those packages has bugs filed to change to mpich on 32 bit
architectures.
To be honest, I don't see these two changes (changing mpi-defaults to
mpich on 32 bit; breaking 32 bit build of openmpi) to be ready. It'd be
preferable to reinstate a 32-bit compatible pmix and fix openmpi on 32
bit until the time_t transition is done.
Cheers

I checked with "build-rdeps libopenmpi-dev" and checked the packages.
They are mostly false-alarms.

What is needed:

* mpich not to use libpmix for 32-bit archs. I've a patch i'm testing.

* armci-mpi builds on both mpich, openmpi. Needs work to only build on
openmpi on 64-bit. #10683219

* code-saturne: Uses the default mpi version of hdf5. #1068318

* adios: fix just uploaded.

* vtk9: Depends on libhdf5-openmpi-dev instead of libhdf5-mpi-dev. #1068321

* trilinos: deps on openmpi , but only available on 64-bit systems. No
change needed

* hdf5: Needs to depend on 64-bit archs for libopenmpi-dev. #1068320

* scalapack: Needs to dep on 64-bit archs only for libopenmpi-dev. #1068322

Regards

Alastair

--
Alastair McKinstry,
GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5
ph: +353 87 6847928 e: ***@mckinstry.ie, im: @alastair:mckinstry.ie

Sebastian Ramacher

2024-04-06 07:50:15 UTC

There is a transition to openmpi-5 / mpi-defaults which is stalled by the
t64 transition.
It drops 32-bit support from OpenMPI.
Because of this, I don't think the solution is to port 32-bit atomics for
armel/armhf, as it will be removed in a few weeks/months.
While we didn't want the transitions to be done simultaneously, it might be
the best answer.
What does the release team think?

Adding another transition on top will just delay the time_t transition
even more. So if we can avoid that, I'd prefer to not do this transition
now. Unfortunately, uploads such as the one of pmix that no dropped
support for 32 bit architectures (#1068211) are not really helpful.
Also, #1064810 has no information on test builds with the new
mpi-defaults on a 32 bit architecture. So has this transition been
tested?
Cheers

OpenMPI 5 drops 32-bit support, but otherwise does not change the API/ABI.
So it is technically not a transition, but breaks 32-bit builds.

Doesn't make it better. This is not the time to do that without tests
builds and bugs filed.

Beside the easy part of chaning mpi-defaults, I count 30 something
packages that have explicit build dependencies on libopenmpi-dev. None
of those packages has bugs filed to change to mpich on 32 bit
architectures.

To be honest, I don't see these two changes (changing mpi-defaults to
mpich on 32 bit; breaking 32 bit build of openmpi) to be ready. It'd be
preferable to reinstate a 32-bit compatible pmix and fix openmpi on 32
bit until the time_t transition is done.

Cheers

--
Sebastian Ramacher

Andrey Rakhmatullin

2024-04-06 07:51:26 UTC

There is a transition to openmpi-5 / mpi-defaults which is stalled by the
t64 transition.
It drops 32-bit support from OpenMPI.
Because of this, I don't think the solution is toÂ port 32-bit atomics for
armel/armhf, as it will be removed in a few weeks/months.
While we didn't want the transitions to be done simultaneously, it might be
the best answer.

It may have been somewhat easier for armel/armhf bootstrapping/rebuilding
if MPI stuff was dropped there early, but that's already finished
successfully so it doesn't matter.
Note that openmpi built successfuly on all release architectures so this
bug doesn't apply to them anyway.

--
WBR, wRAR

Sebastian Ramacher

2024-04-06 07:51:47 UTC

OPAL_THREAD_ADD_FETCH64 is defined under #if OPAL_HAVE_ATOMIC_MATH_64
And I assume this arch doesn't have 64-bit atomics.

No native ones, yes.
I *think* either libatomic or libatomic_ops(?) make them
available, but very slowly, using a syscall to guarantee
atomicity (those systems are normally uniprocessor) on
m68k.
If possible, avoiding them would be preferrable. (For
example, in some cases, like reading a 64-bit timestamp,
if the writing direction is known and stable, reading
twice then comparing is a possible alternative at least
for some architectures (e.g. I know BSD code for sparc
does it that way).
I guess you’ll have to ask the porters of 32-bit arches
with no native 64-bit atomics for details.
Though I had thought GCC’s builtin atomics use the
aforementioned kernel-based workaround from that library
these days?

Adding another transition on top will just delay the time_t transition
even more. So if we can avoid that, I'd prefer to not do this transition
now. Unfortunately, uploads such as the one of pmix that no dropped
support for 32 bit architectures (#1068211) are not really helpful.

Also, #1064810 has no information on test builds with the new
mpi-defaults on a 32 bit architecture. So has this transition been
tested?

Cheers

--
Sebastian Ramacher

Sebastian Ramacher

2024-05-05 16:40:02 UTC

OpenMPI 5.0 drops 32-bit support, so we need to move those archs to MPICH.

This transition is blocking many of the remaining packages rebuilt for
64-bit time_t.
The autopkgtest for slurm-wlm on i386 is blocking testing migration of
https://qa.debian.org/excuses.php?package=mpich
Testing migration of openmpi is likewise blocked by autopkgtest failures on
https://qa.debian.org/excuses.php?package=openmpi
I'm starting to think that it'd be better to drop support for 32bit
architectures from all these rdeps so they can just use openmpi everywhere
and not have i386 autopkgtest failures able to block testing migration.

openmpi should migrate with the next britney run.

After that we can look into starting the transition to change
mpi-defaults on 32 bit architctures. That is currently

https://release.debian.org/transitions/html/mpi-defaults.html

This will also require changes to hdf5. Have they been prepared
somewhere?

Cheers

--
Sebastian Ramacher

Alastair McKinstry

2024-05-06 06:00:02 UTC

OpenMPI 5.0 drops 32-bit support, so we need to move those archs to
MPICH.

This transition is blocking many of the remaining packages rebuilt for
64-bit time_t.
The autopkgtest for slurm-wlm on i386 is blocking testing migration of
https://qa.debian.org/excuses.php?package=mpich
Testing migration of openmpi is likewise blocked by autopkgtest
https://qa.debian.org/excuses.php?package=openmpi
I'm starting to think that it'd be better to drop support for 32bit
architectures from all these rdeps so they can just use openmpi
everywhere and not have i386 autopkgtest failures able to block
testing migration.
Should we advocate this to the maintainer of these packages or is
there something else we can do to improve this situation?

Dropping 32-bit support for so many packages is a bit more radical than
I had considered, but I'd go with it.

Regards

Alastair

Kind Regards,
Bas

--
Alastair McKinstry,
GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5
e: ***@debian.org, im: @alastair:mckinstry.ie

Sebastian Ramacher

2024-07-07 17:30:01 UTC

Control: tags -1 confirmed

Package: release.debian.org
Severity: normal
Usertags: transition
Control: affects -1 + src:mpi-defaults
OpenMPI 5.0 drops 32-bit support, so we need to move those archs to MPICH.

Let's go ahead with this change. Please switch the 32 bit architectures
to mpich.

Cheers

notes = "https://lists.debian.org/debian-release/2023/11/msg00379.html";
title = "mpi-defaults";
is_affected = .build-depends ~ /mpi-default-dev/;
is_good = .depends ~ /libmpich.*/;
is_bad = .depends ~ /libopenmpi.*/;
architectures = [ "armhf","armel","i386" ];
ignored = [ ];

--
Sebastian Ramacher

Debian Bug Tracking System

2024-07-07 17:30:01 UTC

Post by Sebastian Ramacher
tags -1 confirmed

Bug #1064810 [release.debian.org] transition: mpi-defaults
Added tag(s) confirmed.

--
1064810: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064810
Debian Bug Tracking System
Contact ***@bugs.debian.org with problems

Sebastian Ramacher

2024-07-08 10:40:01 UTC

Hi Alastair

Post by Sebastian Ramacher
Control: tags -1 confirmed

Package: release.debian.org
Severity: normal
Usertags: transition
Control: affects -1 + src:mpi-defaults
OpenMPI 5.0 drops 32-bit support, so we need to move those archs to MPICH.

Let's go ahead with this change. Please switch the 32 bit architectures
to mpich.

Thanks for the upload of mpi-defaults. A fix for #1028172 is needed
though to continue with this transition. I would appreciate if you could
take a look at that bug.

Cheers

--
Sebastian Ramacher

Alastair McKinstry

2024-07-08 11:00:01 UTC

Post by Sebastian Ramacher
Hi Alastair

Post by Sebastian Ramacher
Control: tags -1 confirmed

Package: release.debian.org
Severity: normal
Usertags: transition
Control: affects -1 + src:mpi-defaults
OpenMPI 5.0 drops 32-bit support, so we need to move those archs to MPICH.

Let's go ahead with this change. Please switch the 32 bit architectures
to mpich.

Thanks for the upload of mpi-defaults. A fix for #1028172 is needed
though to continue with this transition. I would appreciate if you could
take a look at that bug.

Thanks for highlighting it. I'm preparing a fix now.

Sebastian Ramacher

2024-07-12 22:10:01 UTC

Post by Sebastian Ramacher
Hi Alastair

Post by Sebastian Ramacher
Control: tags -1 confirmed

Package: release.debian.org
Severity: normal
Usertags: transition
Control: affects -1 + src:mpi-defaults
OpenMPI 5.0 drops 32-bit support, so we need to move those archs to MPICH.

Let's go ahead with this change. Please switch the 32 bit architectures
to mpich.

Thanks for the upload of mpi-defaults. A fix for #1028172 is needed
though to continue with this transition. I would appreciate if you could
take a look at that bug.

Thanks for highlighting it. I'm preparing a fix now.

Most of the binNMUs are now scheduled. Not that
https://release.debian.org/transitions/html/mpi-defaults.html still
lists quite a lot of packages. Some FTBFS, but others also depend on
both mpi-defaults and openmpi and build with openmpi. I would appreciate
if you could take a look at those packages and file bugs where
appropriate.

Cheers

--
Sebastian Ramacher

Alastair McKinstry

2024-07-13 10:00:01 UTC

Post by Sebastian Ramacher
Hi Alastair

Post by Sebastian Ramacher
Control: tags -1 confirmed

Package: release.debian.org
Severity: normal
Usertags: transition
Control: affects -1 + src:mpi-defaults
OpenMPI 5.0 drops 32-bit support, so we need to move those archs to MPICH.

Let's go ahead with this change. Please switch the 32 bit architectures
to mpich.

Thanks for the upload of mpi-defaults. A fix for #1028172 is needed
though to continue with this transition. I would appreciate if you could
take a look at that bug.

Thanks for highlighting it. I'm preparing a fix now.

Will do. Thanks

Alastair

Sebastian Ramacher

2024-08-15 09:50:01 UTC

Post by Sebastian Ramacher
Hi Alastair

Post by Sebastian Ramacher
Control: tags -1 confirmed

Package: release.debian.org
Severity: normal
Usertags: transition
Control: affects -1 + src:mpi-defaults
OpenMPI 5.0 drops 32-bit support, so we need to move those archs to MPICH.

Let's go ahead with this change. Please switch the 32 bit architectures
to mpich.

Thanks for the upload of mpi-defaults. A fix for #1028172 is needed
though to continue with this transition. I would appreciate if you could
take a look at that bug.

Thanks for highlighting it. I'm preparing a fix now.

Will do. Thanks

Let's also start the openmpi 32 bit removal transition. The tracker is
https://release.debian.org/transitions/html/openmpi-rm32.html.

Same request as above: please check the packages that are marked as bad
on the tracker and file bugs to change to mpich or drop the 32 bit
binaries as appropriate.

Cheers

--
Sebastian Ramacher

Alastair McKinstry

2024-08-15 10:20:01 UTC

Post by Sebastian Ramacher
Hi Alastair

Post by Sebastian Ramacher
Control: tags -1 confirmed

Package: release.debian.org
Severity: normal
Usertags: transition
Control: affects -1 + src:mpi-defaults
OpenMPI 5.0 drops 32-bit support, so we need to move those archs to MPICH.

Let's go ahead with this change. Please switch the 32 bit architectures
to mpich.

Thanks for the upload of mpi-defaults. A fix for #1028172 is needed
though to continue with this transition. I would appreciate if you could
take a look at that bug.

Thanks for highlighting it. I'm preparing a fix now.

Will do. Thanks

Let's also start the openmpi 32 bit removal transition. The tracker is
https://release.debian.org/transitions/html/openmpi-rm32.html.
Same request as above: please check the packages that are marked as bad
on the tracker and file bugs to change to mpich or drop the 32 bit
binaries as appropriate.
Cheers

Note that mpich got caught up in the gcc 14 transition and FTBFS (#1057292)
I'm working on this as I write, (there is a patch from Adrian Bunk that
fails to install for me, but I have it working now and am testing on amd64).

Regards
Alastair

Sebastian Ramacher

2024-08-21 07:20:01 UTC

Post by Sebastian Ramacher
Hi Alastair

Post by Sebastian Ramacher
Control: tags -1 confirmed

Package: release.debian.org
Severity: normal
Usertags: transition
Control: affects -1 + src:mpi-defaults
OpenMPI 5.0 drops 32-bit support, so we need to move those archs to MPICH.

Let's go ahead with this change. Please switch the 32 bit architectures
to mpich.

Thanks for the upload of mpi-defaults. A fix for #1028172 is needed
though to continue with this transition. I would appreciate if you could
take a look at that bug.

Thanks for highlighting it. I'm preparing a fix now.

Will do. Thanks

Let's also start the openmpi 32 bit removal transition. The tracker is
https://release.debian.org/transitions/html/openmpi-rm32.html.
Same request as above: please check the packages that are marked as bad
on the tracker and file bugs to change to mpich or drop the 32 bit
binaries as appropriate.
Cheers

Thanks, this upload now made its way into testing.

Cheers

--
Sebastian Ramacher

Sebastian Ramacher

2024-10-04 22:00:02 UTC

Hi Alastair

Post by Sebastian Ramacher
Hi Alastair

Post by Sebastian Ramacher
Control: tags -1 confirmed

Package: release.debian.org
Severity: normal
Usertags: transition
Control: affects -1 + src:mpi-defaults
OpenMPI 5.0 drops 32-bit support, so we need to move those archs to MPICH.

Let's go ahead with this change. Please switch the 32 bit architectures
to mpich.

Thanks for the upload of mpi-defaults. A fix for #1028172 is needed
though to continue with this transition. I would appreciate if you could
take a look at that bug.

Thanks for highlighting it. I'm preparing a fix now.

Will do. Thanks

Let's also start the openmpi 32 bit removal transition. The tracker is
https://release.debian.org/transitions/html/openmpi-rm32.html.
Same request as above: please check the packages that are marked as bad
on the tracker and file bugs to change to mpich or drop the 32 bit
binaries as appropriate.
Cheers

Thanks, this upload now made its way into testing.

Are there any news regarding the upload of openmpi removing 32 bit
support?

Cheers

--
Sebastian Ramacher

Alastair McKinstry

2024-10-07 10:10:02 UTC

Hi Sebastian

Post by Sebastian Ramacher
Hi Alastair

Post by Sebastian Ramacher
Hi Alastair

Post by Sebastian Ramacher
Control: tags -1 confirmed

Package: release.debian.org
Severity: normal
Usertags: transition
Control: affects -1 + src:mpi-defaults
OpenMPI 5.0 drops 32-bit support, so we need to move those archs to MPICH.

Let's go ahead with this change. Please switch the 32 bit architectures
to mpich.

Thanks for the upload of mpi-defaults. A fix for #1028172 is needed
though to continue with this transition. I would appreciate if you could
take a look at that bug.

Thanks for highlighting it. I'm preparing a fix now.

Will do. Thanks

Let's also start the openmpi 32 bit removal transition. The tracker is
https://release.debian.org/transitions/html/openmpi-rm32.html.
Same request as above: please check the packages that are marked as bad
on the tracker and file bugs to change to mpich or drop the 32 bit
binaries as appropriate.
Cheers

Thanks, this upload now made its way into testing.

Are there any news regarding the upload of openmpi removing 32 bit
support?
Cheers

I need to do more bug submissions on the transition but mpich is
present, and I can upload openmpi 5

(there is a bug
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078212 that I will
close on uploading 5.0.5). I will do so when the Release Team agrees.

Regards

Alastair

Sebastian Ramacher

2024-10-12 11:40:01 UTC

Hi Alastair

Post by Sebastian Ramacher
Let's also start the openmpi 32 bit removal transition. The tracker is
https://release.debian.org/transitions/html/openmpi-rm32.html.
Same request as above: please check the packages that are marked as bad
on the tracker and file bugs to change to mpich or drop the 32 bit
binaries as appropriate.
Cheers

Thanks, this upload now made its way into testing.

Are there any news regarding the upload of openmpi removing 32 bit
support?
Cheers

I need to do more bug submissions on the transition but mpich is present,
and I can upload openmpi 5
(there is a bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078212
that I will close on uploading 5.0.5). I will do so when the Release Team
agrees.

ACK, from our side this is good to go.

Cheers

--
Sebastian Ramacher

Alastair McKinstry

2024-10-14 13:50:02 UTC

Hi Sebastian

Post by Sebastian Ramacher
Hi Alastair

Thanks, this upload now made its way into testing.

Are there any news regarding the upload of openmpi removing 32 bit
support?
Cheers

I need to do more bug submissions on the transition but mpich is present,
and I can upload openmpi 5
(there is a bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078212
that I will close on uploading 5.0.5). I will do so when the Release Team
agrees.

ACK, from our side this is good to go.
Cheers

Ok this is uploaded and through britney, though I need to bring git up
to date on salsa.

I'll be submitting bugs on the remaining packages.

Thanks

Alastair

--
Alastair McKinstry,
GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5
e: ***@mckinstry.ie, im: @alastair:mckinstry.ie @***@mastodon.ie

Commander Vimes didn’t like the phrase “The innocent have nothing to fear,”
believing the innocent had everything to fear, mostly from the guilty but in the longer term
even more from those who say things like “The innocent have nothing to fear.”
- T. Pratchett, Snuff

Sebastian Ramacher

2024-10-15 19:40:02 UTC

Thanks, this upload now made its way into testing.

Are there any news regarding the upload of openmpi removing 32 bit
support?
Cheers

I need to do more bug submissions on the transition but mpich is present,
and I can upload openmpi 5
(there is a bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078212
that I will close on uploading 5.0.5). I will do so when the Release Team
agrees.

ACK, from our side this is good to go.
Cheers

Ok this is uploaded and through britney, though I need to bring git up to
date on salsa.
I'll be submitting bugs on the remaining packages.

openmpi failed to build on Architecture: all. Could you please take a
look?

Cheers

--
Sebastian Ramacher

Adrian Bunk

2024-10-18 21:10:01 UTC

...
Ok this is uploaded and through britney, though I need to bring git up to
date on salsa.
...

Various packages (e.g. combblas, superlu-dist, trilinos) are linked with
the libmpi_cxx that was removed in openmpi 5.

A rebuild seems to fix it.

The clean solution would be renaming the library package
(e.g. libopenmpi40), and then a transition to rebuild all
reverse dependencies.

Thanks
Alastair

cu
Adrian

Graham Inggs

2024-10-20 10:10:01 UTC

I'm copying the following email to the bug.

...
Ok this is uploaded and through britney, though I need to bring git up to
date on salsa.
...

Various packages (e.g. combblas, superlu-dist, trilinos) are linked with
the libmpi_cxx that was removed in openmpi 5.
A rebuild seems to fix it.
The clean solution would be renaming the library package
(e.g. libopenmpi40), and then a transition to rebuild all
reverse dependencies.

Thanks
Alastair

cu
Adrian

Alastair McKinstry

2024-10-21 05:20:01 UTC

...
Ok this is uploaded and through britney, though I need to bring git up to
date on salsa.
...

Various packages (e.g. combblas, superlu-dist, trilinos) are linked with
the libmpi_cxx that was removed in openmpi 5.
A rebuild seems to fix it.
The clean solution would be renaming the library package
(e.g. libopenmpi40), and then a transition to rebuild all
reverse dependencies.
cu
Adrian

I'll prepare this now for debian/experimental. Is there an example of
good practice with breaks/replaces/provides when doing two transitions
in one release, ie libopenmpi3->libopenmpi3t64->libopenmpi40 ?

Thanks

Alastair

Paul Gevers

2024-10-21 05:50:01 UTC

Hi,

Post by Alastair McKinstry
I'll prepare this now for debian/experimental. Is there an example of
good practice with breaks/replaces/provides when doing two transitions
in one release, ie libopenmpi3->libopenmpi3t64->libopenmpi40 ?

You can't add a provides, otherwise you wouldn't need the rename.
Normally library packages as co-installable (that's why we want new
binary packages with SONAME matching names) and you don't need any
breaks/replaces.

Having said that, I think you can just add a Breaks/Replaces on
libopenmpi3t64 in same way you already have it for libopenmpi3.

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.
"""

Paul

[1]
https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#run-time-shared-libraries

Adrian Bunk

2024-11-04 09:30:01 UTC

...
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
"""
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 libmpi_cxx 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.

Paul
...

cu
Adrian

Alastair McKinstry

2024-11-04 09:50:01 UTC

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.

Longer term, we need to add symbols to OpenMPI to avoid transitions.

Alastair

Paul
...

cu
Adrian

--
Alastair McKinstry,
GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5
e:***@mckinstry.ie, im: @alastair:mckinstry.ie @***@mastodon.ie

Commander Vimes didnât like the phrase âThe innocent have nothing to fear,â
believing the innocent had everything to fear, mostly from the guilty but in the longer term
even more from those who say things like âThe innocent have nothing to fear.â
- T. Pratchett, Snuff

Adrian Bunk

2024-11-04 10:20:01 UTC

Post by Alastair McKinstry
Hi

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.

Post by Alastair McKinstry
Longer term, we need to add symbols to OpenMPI to avoid transitions.

Symbols don't avoid transitions.

Post by Alastair McKinstry
Alastair

cu
Adrian

Alastair McKinstry

2024-11-04 12:50:01 UTC

Post by Alastair McKinstry
Hi
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.

I really doubt mixing libraries from 5 and 6 would work.

Post by Alastair McKinstry
Longer term, we need to add symbols to OpenMPI to avoid transitions.

Symbols don't avoid transitions.

Some transitions. They don't stop all,eg removing libraries and
functionality.Â But they've been relatively successful in eg glibc and
MPI itself is pretty conservative in removing stuff.

Post by Alastair McKinstry
Alastair

cu
Adrian

Drew Parsons

2024-10-19 14:10:01 UTC

The upload of openmpi 5 removed libmpi_cxx.so.

So all packages linked against libmpi_cxx.so need to be rebuilt.

Debian Bug Tracking System

2025-01-07 10:20:01 UTC