Bug#1102465: petsc: PETSc was configured with one MPICH/Open MPI mpi.h version but now appears to be compiling using an older version

[Adrian Bunk]

On Fri, Oct 23, 2026 at 08:06:20AM +0200, Andreas Tille wrote:
> Hi,

Hi Andreas,

> Am Mon, Oct 05, 2026 at 03:21:01AM +0300 schrieb Adrian Bunk:
> > > https://gitlab.com/petsc/petsc/-/work_items/1881
> > 
> > Since we are hitting the problem again, could you add something like the 
> > attached patch?
> 
> Thank you Adrian for the patch.
> 
> I wonder whether we could circumvent this kind of trouble by adding
> architecture-is-64-bit to Build-Depends. This would mean we need to
> ask for removal of quite a number of binary packages, thought.

I wonder if people could stop this kind of architecture restriction 
trouble by trying to understand problems first instead of blindly
adding architecture-is-64-bit.

architecture-is-64-bit is not a solution for a normal bug.

The OpenMPI part of this bug could even be "solved" with
architecture-is-32-bit (sic).

It puzzles me how people even start considering adding architecture-is-64-bit
when nothing in a bug hints at an unsolvable 32-bit issue.

This bug is a case of a runtime check not matching the package 
dependencies, and either of these has to be fixed.

> But in the end I think this is no practical restriction for our users
> and we might get rid of some maintenance burden.

Architecture restrictions are also a maintenance burden.

When you go through the transitive rdeps of petsc, you will e.g. realize
that adding architecture-is-64-bit would force octave to hardcode and 
maintain a manual architecture list in its sundials build dependency.

And then you have different functionality of octave on different 
architectures, which could result in follow-up build or runtime issues.

> Kind regards
>     Andreas.

cu
Adrian