Hi

I've been pinged by the upstream maintainer of OpenMPI    Jefff Squyres
as to our opinions on maintaining 32-bit support.

See a  thread here: https://github.com/open-mpi/ompi/pull/11282

Until now I've asked for OMPI to hold off going to 64-bit only; saying
we can help with the maintenance burden with our testing infrastructure.

But we're not well suited to run multi-node test jobs.

If 32-bit support is dropped in OMPI we can switch to MPICH as the
default on those archs instead, but the core problem remains: how much
can we support and test on 32-bit?

(Note:  We're at OpenMPI 4.1.4 now for Bookworm; no change planned)

Comments please,


Alastair McKinstry

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-02-07 10:54, Alastair McKinstry wrote:

Hi

I've been pinged by the upstream maintainer of OpenMPI    Jefff
Squyres as to our opinions on maintaining 32-bit support.

See a  thread here: https://github.com/open-mpi/ompi/pull/11282

Until now I've asked for OMPI to hold off going to 64-bit only; saying
we can help with the maintenance burden with our testing
infrastructure.

But we're not well suited to run multi-node test jobs.

If Lucas Nussbaum thinks it's appropriate, one thing we could consider
is setting up multinode tests on the Grid'5000 [1] infrastructure. It
would take a bit of effort to set up, but once set up it should be able
to run multinode tests routinely. Although, true, it would only allow
for 64-bit testing, i.e. amd64 (plus also arm64 and ppc64el), so it
might not help with the question of 32-bit support unless 32-bit chroots
can be set up.

[1] https://www.grid5000.fr

If 32-bit support is dropped in OMPI we can switch to MPICH as the
default on those archs instead, but the core problem remains: how much
can we support and test on 32-bit?

Switching to mpich would in any case be supported by a lot of our
upstream developers. In various different projects we hear them
recommending mpich and occasionally expressing discontent with bugs in
openmpi.

To make it simpler for ourselves, we could also consider just switching
to mpich altogether as default. Are there reasons to prefer 64-bit OMPI
over MPICH?

Drew

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Alastair,

Thanks for relaying OpenMPI's upstream
maintainer's interest in our opinions on
maintaining 32 bit support.

My humble comments are

1.) 32 bit hardware can be more secure because
it's so old it predates back doors known as

Intel's Management Engine[1] and

AMD's Platform Secure Processor[2]

2.) and I'm OK with reporting bugs.

Thanks again,
Kingsley


[1] https://en.wikipedia.org/wiki/Intel_Management_Engine#Security_vulnerabilities

[2] https://en.wikipedia.org/wiki/AMD_Platform_Security_Processor#Reported_vulnerabilities




On 02/07/2023 09:54, Alastair McKinstry wrote:

Hi

I've been pinged by the upstream maintainer of OpenMPI    Jefff Squyres as
to our opinions on maintaining 32-bit support.

See a  thread here: https://github.com/open-mpi/ompi/pull/11282

Until now I've asked for OMPI to hold off going to 64-bit only; saying we
can help with the maintenance burden with our testing infrastructure.

But we're not well suited to run multi-node test jobs.

If 32-bit support is dropped in OMPI we can switch to MPICH as the default
on those archs instead, but the core problem remains: how much can we
support and test on 32-bit?

(Note:  We're at OpenMPI 4.1.4 now for Bookworm; no change planned)

Comments please,

Alastair McKinstry

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

--
Time is the fire in which we all burn.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 07/02/2023 10:27, Drew Parsons wrote:

On 2023-02-07 10:54, Alastair McKinstry wrote:

Hi

I've been pinged by the upstream maintainer of OpenMPI    Jefff
Squyres as to our opinions on maintaining 32-bit support.

See a  thread here: https://github.com/open-mpi/ompi/pull/11282

If 32-bit support is dropped in OMPI we can switch to MPICH as the
default on those archs instead, but the core problem remains: how much
can we support and test on 32-bit?

Switching to mpich would in any case be supported by a lot of our
upstream developers.  In various different projects we hear them recommending mpich and occasionally expressing discontent with bugs in openmpi.

I've heard this, but at the same time heard that one of the benefits of
OpenMPI is the larger test suite and infrastructure, which is puzzling.

My experience is that OpenMPI is faster on release of support for new
systems such as PMIx, UCX; this shakes out bugs there first before MPICH;

also MPICH has at times been harder to build, looking like many
configurations are not tested as well.

Can you point to the upstream bugs?

To make it simpler for ourselves, we could also consider just
switching to mpich altogether as default.  Are there reasons to prefer 64-bit OMPI over MPICH?

Drew

Alastair

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

The push-back from upstream is that they're unconvinced anyone is
actually using i386 for MPI.

For example, MPI is configured to use PMIx but its thought that doesn't
work on 32-bit, but no bugs have been reported.

Either we increase our 32-bit testing regime, or realistically consider
it marginal and dying.

Currently I'm favouring accepting a move to 64-bit OpenMPI as a fait
accompli as part of code cleanups for 5.X (post Bookworm), and Debian
moving to MPICH on at least 32-bit archs - I'd favour OpenMPI on 64-bit
archs for better incoming-code-and-compatability support.

I'd like to hear the case otherwise.


Best regards
Alastair


On 07/02/2023 20:22, Kingsley G. Morse Jr. wrote:

Hi Alastair,

Thanks for relaying OpenMPI's upstream
maintainer's interest in our opinions on
maintaining 32 bit support.

My humble comments are

1.) 32 bit hardware can be more secure because
it's so old it predates back doors known as

Intel's Management Engine[1] and

AMD's Platform Secure Processor[2]

2.) and I'm OK with reporting bugs.

Thanks again,
Kingsley

[1] https://en.wikipedia.org/wiki/Intel_Management_Engine#Security_vulnerabilities

[2] https://en.wikipedia.org/wiki/AMD_Platform_Security_Processor#Reported_vulnerabilities

On 02/07/2023 09:54, Alastair McKinstry wrote:

Hi

I've been pinged by the upstream maintainer of OpenMPI    Jefff Squyres as >> to our opinions on maintaining 32-bit support.

See a  thread here: https://github.com/open-mpi/ompi/pull/11282

Until now I've asked for OMPI to hold off going to 64-bit only; saying we
can help with the maintenance burden with our testing infrastructure.

But we're not well suited to run multi-node test jobs.

If 32-bit support is dropped in OMPI we can switch to MPICH as the default >> on those archs instead, but the core problem remains: how much can we
support and test on 32-bit?

(Note:  We're at OpenMPI 4.1.4 now for Bookworm; no change planned)

Comments please,


Alastair McKinstry

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

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, Feb 09, 2023 at 09:53:37AM +0000, Alastair McKinstry wrote:

Hi,

The push-back from upstream is that they're unconvinced anyone is actually using i386 for MPI.

For example, MPI is configured to use PMIx but its thought that doesn't work on 32-bit, but no bugs have been reported.

Either we increase our 32-bit testing regime, or realistically consider it marginal and dying.

I don't think lack of testing is the problem, we should have pretty good coverage due to buildtime and autopkgtest tests.

There are bugs like e.g. #1003020 or #1026912 that might be due to
OpenMPI failing on 32-bit with 160 cores.

Whether spending time trying to properly fix these would be worth it,
that's a different question.

Currently I'm favouring accepting a move to 64-bit OpenMPI as a fait
accompli as part of code cleanups for 5.X (post Bookworm), and Debian moving to MPICH on at least 32-bit archs - I'd favour OpenMPI on 64-bit archs for better incoming-code-and-compatability support.

I'd like to hear the case otherwise.

The case we should make is that "no one cares about 32-bit builds" from
the starting post in the GitHub issue is not true for Debian.
We do care that it *builds*, even if it might not be actually used.

[1] was about the benefits of switching the two architectures that were
using MPICH to OpenMPI two years ago. The mentioned "makes packages like
octave build" is due to sundials build depending on mpi-default-dev but requiring ompi-c.pc [2].

m68k and sh4 are building with nocheck, whether or not there might be additional/different test failures in packages with MPICH is unknown.

Having different MPI implementations on different architectures again
would be painful for us, especially if it would be on release architectures.

If it would be architecturally hard for upstream to continue supporting
32-bit then that's how it is, otherwise the current status quo of 32-bit OpenMPI is good enough for us and a possible compromise might be if
upstream says "32-bit patches are welcome" and requires an
--i-know-that-32-bit-support-is-unsupported-and-might-be-broken
configure flag when building for 32-bit archs.

Best regards
Alastair

cu
Adrian

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853029#18
[2] https://buildd.debian.org/status/fetch.php?pkg=sundials&arch=m68k&ver=5.7.0%2Bdfsg-1~exp1&stamp=1626976038&raw=0

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is a multi-part message in MIME format.

Currently I'm favouring accepting a move to 64-bit OpenMPI as a fait
accompli as part of code cleanups for 5.X (post Bookworm), and Debian moving >> to MPICH on at least 32-bit archs - I'd favour OpenMPI on 64-bit archs for >> better incoming-code-and-compatability support.

I'd like to hear the case otherwise.

The case we should make is that "no one cares about 32-bit builds" from
the starting post in the GitHub issue is not true for Debian.
We do care that it *builds*, even if it might not be actually used.

I've been making this point, mostly in the context of avoiding a future
where no MPI is available on 32-bit
(and by implication, essentially forking Debian into a toy 32-bit world
and a properly-supported 64-bit one).

[1] was about the benefits of switching the two architectures that were
using MPICH to OpenMPI two years ago. The mentioned "makes packages like octave build" is due to sundials build depending on mpi-default-dev but requiring ompi-c.pc [2].

m68k and sh4 are building with nocheck, whether or not there might be additional/different test failures in packages with MPICH is unknown.

Having different MPI implementations on different architectures again
would be painful for us, especially if it would be on release architectures.

If it would be architecturally hard for upstream to continue supporting 32-bit then that's how it is, otherwise the current status quo of 32-bit OpenMPI is good enough for us and a possible compromise might be if
upstream says "32-bit patches are welcome" and requires an
--i-know-that-32-bit-support-is-unsupported-and-might-be-broken
configure flag when building for 32-bit archs.

Such a flag is possible and being debated.

The challenge is key dependencies will move on to being 64-bit only,
too: PMIx, etc.

The point of going  64-bit only is to clean up data structures and
remove technical debt: Hence 5.x will start a cleanup and removal of
32-bit code.

The next point release may work on 32-bit by just bypassing the
compilation flag; ongoing support starts meaning more invasive patches
need to be carried by us.

Best regards
Alastair

cu
Adrian

[1]https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853029#18 [2]https://buildd.debian.org/status/fetch.php?pkg=sundials&arch=m68k&ver=5.7.0%2Bdfsg-1~exp1&stamp=1626976038&raw=0

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

<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<span style="white-space: pre-wrap">
</span>
<blockquote type="cite" cite="mid:Y+gSBb%2FlFin3ouf0@localhost">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Currently I'm favouring accepting a move to 64-bit OpenMPI as a fait
accompli as part of code cleanups for 5.X (post Bookworm), and Debian moving
to MPICH on at least 32-bit archs - I'd favour OpenMPI on 64-bit archs for better incoming-code-and-compatability support.

I'd like to hear the case otherwise.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
The case we should make is that "no one cares about 32-bit builds" from
the starting post in the GitHub issue is not true for Debian.
We do care that it *builds*, even if it might not be actually used.
</pre>
</blockquote>
I've been making this point, mostly in the context of avoiding a
future where no MPI is available on 32-bit<br>
(and by implication, essentially forking Debian into a toy 32-bit
world and a properly-supported 64-bit one).<br>
<blockquote type="cite" cite="mid:Y+gSBb%2FlFin3ouf0@localhost">
<pre class="moz-quote-pre" wrap="">
[1] was about the benefits of switching the two architectures that were
using MPICH to OpenMPI two years ago. The mentioned "makes packages like
octave build" is due to sundials build depending on mpi-default-dev but requiring ompi-c.pc [2].

m68k and sh4 are building with nocheck, whether or not there might be additional/different test failures in packages with MPICH is unknown.

Having different MPI implementations on different architectures again
would be painful for us, especially if it would be on release architectures.

If it would be architecturally hard for upstream to continue supporting
32-bit then that's how it is, otherwise the current status quo of 32-bit OpenMPI is good enough for us and a possible compromise might be if
upstream says "32-bit patches are welcome" and requires an
--i-know-that-32-bit-support-is-unsupported-and-might-be-broken
configure flag when building for 32-bit archs.
</pre>
</blockquote>
<p>Such a flag is possible and being debated.</p>
<p>The challenge is key dependencies will move on to being 64-bit
only, too: PMIx, etc.</p>
<p>The point of going  64-bit only is to clean up data structures
and remove technical debt: Hence 5.x will start a cleanup and
removal of 32-bit code.</p>
<p>The next point release may work on 32-bit by just bypassing the
compilation flag; ongoing support starts meaning more invasive
patches need to be carried by us. <br>
</p>
<blockquote type="cite" cite="mid:Y+gSBb%2FlFin3ouf0@localhost">
<pre class="moz-quote-pre" wrap="">
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Best regards
Alastair
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
cu
Adrian

[1] <a class="moz-txt-link-freetext" href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853029#18">https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853029#18</a>
[2] <a class="moz-txt-link-freetext" href="https://buildd.debian.org/status/fetch.php?pkg=sundials&amp;arch=m68k&amp;ver=5.7.0%2Bdfsg-1~exp1&amp;stamp=1626976038&amp;raw=0">https://buildd.debian.org/status/fetch.php?pkg=sundials&amp;arch=m68k&amp;ver=5.7.
0%2Bdfsg-1~exp1&amp;stamp=1626976038&amp;raw=0</a>

</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Alastair McKinstry,
GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5
ph: +353 87 6847928 e: <a class="moz-txt-link-abbreviated" href="mailto:alastair@sceal.ie">alastair@sceal.ie</a>, im: @sceal.ie:mckinstry</pre>
</body>
</html>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Feb 13, 2023 at 10:59:18AM +0000, Alastair McKinstry wrote:

...

The case we should make is that "no one cares about 32-bit builds" from
the starting post in the GitHub issue is not true for Debian.
We do care that it *builds*, even if it might not be actually used.

I've been making this point, mostly in the context of avoiding a future
where no MPI is available on 32-bit
(and by implication, essentially forking Debian into a toy 32-bit world and
a properly-supported 64-bit one).

I don't see what important functionality for 32-bit today would be
missing without MPI, it is just more work and breakages to have packages configured differently on different platforms to continue providing the functionality that is still important.

...
The point of going  64-bit only is to clean up data structures and remove technical debt: Hence 5.x will start a cleanup and removal of 32-bit code.

The next point release may work on 32-bit by just bypassing the compilation flag; ongoing support starts meaning more invasive patches need to be
carried by us.

This sounds as if the lesser evil for us will be to configure packages differently when one or all MPI implementations are going away on 32-bit.

For example:
ffmpeg -> codec2 -> octave -> sundials -> sundials does not build with MPICH One of these four arrows must be broken.
That's work and not fun work, but likely the lesser evil.

cu
Adrian

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 13/02/2023 12:51, Adrian Bunk wrote:

On Mon, Feb 13, 2023 at 10:59:18AM +0000, Alastair McKinstry wrote:

...

The case we should make is that "no one cares about 32-bit builds" from
the starting post in the GitHub issue is not true for Debian.
We do care that it *builds*, even if it might not be actually used.

I've been making this point, mostly in the context of avoiding a future
where no MPI is available on 32-bit
(and by implication, essentially forking Debian into a toy 32-bit world and >> a properly-supported 64-bit one).

I don't see what important functionality for 32-bit today would be
missing without MPI, it is just more work and breakages to have packages configured differently on different platforms to continue providing the functionality that is still important.

There are a significant number of science libraries dependent on MPI.

We would need to do MPI-free builds of these libraries; I'm not sure how
much breaks as we do.

...
The point of going  64-bit only is to clean up data structures and remove >> technical debt: Hence 5.x will start a cleanup and removal of 32-bit code. >>
The next point release may work on 32-bit by just bypassing the compilation >> flag; ongoing support starts meaning more invasive patches need to be
carried by us.

This sounds as if the lesser evil for us will be to configure packages differently when one or all MPI implementations are going away on 32-bit.

For example:
ffmpeg -> codec2 -> octave -> sundials -> sundials does not build with MPICH One of these four arrows must be broken.
That's work and not fun work, but likely the lesser evil.

Yes.

I suspect that the real problem may be the support of underlying
libraries shared by both implementations,

eg PMIx.  If we can keep a version of MPI that works on generic hardware (TCP/IP) we may be ok.

cu
Adrian

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Feb 13, 2023 at 02:18:06PM +0000, Alastair McKinstry wrote:

On 13/02/2023 12:51, Adrian Bunk wrote:

On Mon, Feb 13, 2023 at 10:59:18AM +0000, Alastair McKinstry wrote:

...

The case we should make is that "no one cares about 32-bit builds" from the starting post in the GitHub issue is not true for Debian.
We do care that it *builds*, even if it might not be actually used.

I've been making this point, mostly in the context of avoiding a future where no MPI is available on 32-bit
(and by implication, essentially forking Debian into a toy 32-bit world and
a properly-supported 64-bit one).

I don't see what important functionality for 32-bit today would be
missing without MPI, it is just more work and breakages to have packages configured differently on different platforms to continue providing the functionality that is still important.

There are a significant number of science libraries dependent on MPI.

We would need to do MPI-free builds of these libraries; I'm not sure how
much breaks as we do.

Would we, though? Or should we remove the 32-bit builds of those libraries
as well?

I think it's accurate that no one is using those scientific libraries in production (which is, basically: doing lots of matrix math) on 32-bit architectures, because all of the vector instructions you want for such work are only available on 64-bit CPUs.

So the only application of those 32-bit binaries, really, is either a)
letting users of those 32-bit archs learn the tools on the hardware they
have available, so they can use them to advantage later on fit-for-purpose hardware; or b) using them to build other software in Debian.

Is either of those a compelling reason to keep building those software
stacks for 32-bit? I would argue not. But neither is it obvious at what
point it's worth the effort to remove them, since this requires tracking the reverse-dependency tree, working out which of those reverse-dependencies are *not* scientific applications that should drop the build-dependency rather
than being removed, and so forth.

So it's a tradeoff between the maintenance work of keeping mpi working on 32-bit, and the one-time work of removing it.

...
The point of going  64-bit only is to clean up data structures and remove technical debt: Hence 5.x will start a cleanup and removal of 32-bit code.

The next point release may work on 32-bit by just bypassing the compilation flag; ongoing support starts meaning more invasive patches need to be carried by us.

--
Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEErEg/aN5yj0PyIC/KVo0w8yGyEz0FAmPsJFsACgkQVo0w8yGy Ez1nMg/7BToD5X02as7oTb1kg1xivgDwWkEpccdAudH+VMwd4WMMyEvn1vQPxsN8 xkCqV9YqfB+Xxn6nx/Ki3PC9PPVdwycpYd6YOo4p7t3Id9tqYw2ZI8w4wCyKL0AB 2wGAFVJGmX4PTbCSLHC32ihqTOoV2OXAwpkirEyGbX+JtGNVa5Ptv6XCfG3CNOzw NsdRaXBdKYGvXcoYDWRUrFBsdI1VR1cCw3Iwn9Zf0osy9q1whjahpTW6qqcugB2O yMznvrdMrvounov5SBcL0mS/QZhck3CDN7Ty6ekUC7Mym8iSoo5dPVqmCrlxKG0P Xg2TtbO+lXssov/J7htmbEc0hvzbutB3+pELv962ojaznr7lCcCykSL0cbhoQCBZ sGWZKO+fNQdducHryJiZJ6ZYLxt6SIUcI6pgCayK3bUEoV7oVh/+oYG0uTC0T9eL +nmGq4Yu/RL3VRSK8BNxzLvh7Zv+QSb8DW/6k6v8AhUMc68DxJ8B02fk4Y/TspWL r0pMdNOaCnask7bH4OO8qj4wCOcTx1SWKDDNZX4Dp5zoHsOR+dOi46UDM/yC0A// Zc92EOp4Q7NtYSVvxpGR

On 15/02/2023 00:16, Steve Langasek wrote:

On Mon, Feb 13, 2023 at 02:18:06PM +0000, Alastair McKinstry wrote:

On 13/02/2023 12:51, Adrian Bunk wrote:
There are a significant number of science libraries dependent on MPI.
We would need to do MPI-free builds of these libraries; I'm not sure how
much breaks as we do.

Would we, though? Or should we remove the 32-bit builds of those libraries as well?

I think it's accurate that no one is using those scientific libraries in production (which is, basically: doing lots of matrix math) on 32-bit architectures, because all of the vector instructions you want for such work are only available on 64-bit CPUs.

So the only application of those 32-bit binaries, really, is either a) letting users of those 32-bit archs learn the tools on the hardware they
have available, so they can use them to advantage later on fit-for-purpose hardware; or b) using them to build other software in Debian.

Is either of those a compelling reason to keep building those software
stacks for 32-bit? I would argue not. But neither is it obvious at what point it's worth the effort to remove them, since this requires tracking the reverse-dependency tree, working out which of those reverse-dependencies are *not* scientific applications that should drop the build-dependency rather than being removed, and so forth.

So it's a tradeoff between the maintenance work of keeping mpi working on 32-bit, and the one-time work of removing it.

Thats a more drastic solution, but also realistic. There are a number of scientific libraries and packages that will never realistically be used;

they're only being built and tested for code quality checking, but add a technical maintenance cost.

The counterpoint is if someone does a high-core-count 32-bit arch for
HPC; x32 could (have been) such an architecture, but its development
looks stalled.

regards

Alastair


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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Feb 14, 2023 at 04:16:33PM -0800, Steve Langasek wrote:

...
working out which of those reverse-dependencies are
*not* scientific applications that should drop the build-dependency rather than being removed, and so forth.

So it's a tradeoff between the maintenance work of keeping mpi working on 32-bit, and the one-time work of removing it.
...

Unfortunately your "one-time work" is not true.


Architecture specific differences are not unlikely to cause FTBFS later,
e.g. when bumping dh compat changes --list-missing to --fail-missing.

Symbols files for shared libraries can be a real pain when there are architecture specific differences that result in different symbols,
dropping symbols files for such libraries might be the best option.


New dependencies on the packages that are removed/unavailable on
some architectures will appear all the time, an example:

Some architectures in ports do not have the complete Haskell ecosystem.

pandoc is written in Haskell.

src:flac builds both a widely used libflac and a rarely used flac
command-line program.

Upstream of src:flac recently switched from docbook-to-man to using
pandoc for generating the manpage for the command-line program.
This made the new libflac unavailable on several ports architectures.

Someone will have to make the build dependency on pandoc and the
contents of debian/flac.install architecture-dependent, or create
a separate binary-all flac-common package for the manpage.


cu
Adrian

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Feb 15, 2023 at 11:29:25AM +0000, Alastair McKinstry wrote:

The counterpoint is if someone does a high-core-count 32-bit arch for
HPC; x32 could (have been) such an architecture, but its development
looks stalled.

That may have been a possibility 15-20 years ago, but today anything
calling itself "HPC" is working with datasets large enough that trying
to use 32 bit pointers would be far more trouble than it's worth; x32 is
of interest to container services far more than HPC, IMO. (Even the GPUs
have working sets above 4GB currently--the days of a viable 32 bit
architecture in this space are entirely in the rear view mirror.)

I personally think it makes far more sense to excise MPI from
architectures where it will never realistically be used than it does to
try to keep it going just to have it.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)