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

[Drew Parsons]

Source: petsc
Followup-For: Bug #1102465
Control: block 1102465 by 1102612
Control: severity 1102465 normal

Thinking about it further, I don't think we have a bug here as such,
and I'm therefore lowering severity.

I don't think any action is needed either. The latest petsc build requires
the latest mpich (on 32-bit arches). But the latest mpich has not yet
migrated to testing.  petsc will pass fine once mpich migrates
(petsc is not blocking mpich).

Two alternative actions could be taken.

1) We could remove upstream's mpich version check, as you suggested.
I'm reluctant to take this step, however. Upstream is careful with
their code, I imagine they put the version check there for a reason.

2) We could add an mpich versioned depends to the petsc packages, so
when a new petsc build is tested in testing, it pulls any new mpich
version with it.  But this would not actually achieve anything. It
would give a clean migration test, but end up "ready to migrate,
waiting for mpich". Which is the state it's currently in, anyway.
So this option would significantly complicate build scripts
(significantly, because only the 32-bit arches use mpich, so complex
logic would need to be added to debian/rules to differentiate the
different mpi-default conditions), and would provide no functional gain.

So I think for this bug it's just patience that is required,
and perhaps assistance with mpich issues (Bug#1102612 is weird).