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

[Paul Gevers]

Hi Drew,

On Fri, 11 Apr 2025 12:23:45 +0200 Drew Parsons <dparsons at debian.org> wrote:
> 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.


But in Debian as you explain below, it doesn't really serve a purpose as 
we're a distribution that ships things together. But ...

> 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 does. It shows to all people inspecting the situation exactly what's 
going on. It would ensure that the migration software triggers the right 
combinations. The other way around, it might also prevent mpich from 
migrating too early in the future (with an upper bound, I haven't 
checked if that's the case here). It would also prevent people from 
doing partial upgrades (yes, not officially supported yet but we're 
getting better at it since autopkgtest catch so many of those and a lot 
of maintainers add versioned Depends). It would prevent running those 
tests (several are quite long running) over and over again (we retry 
after a day) because a passing test is remembered for a long time.

> 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),


This is a valid argument too, I don't deny that at all. (Although, you 
don't have to make it complex and could add things manually (now). I 
agree that's probably a PITA.)

> and would provide no functional gain.


But this I disagree with. Why would we even have invented versioned 
Depends in the first place if people agreed this were true?

I'm not saying the petsc package should have this logic, I leave that up 
to you, but I do think there's more value in it than you seem to see.

So, coming back to point 1, I think that version testing in Debian 
usually is wrong. The best case is when upstream gets it right. The 
great thing is we have versioned Depends to express that at install 
time. Worse case upstream is wrong, usually too tight. We see that *a 
lot* and the version checks make it harder for packages to migrate as 
they need packages to be upgraded in lock step. Regularly because the 
migration doesn't see *why* the tests fail, it doesn't know there's a 
solution by testing together and migrating together if not expressed in 
relations. And then even upstream may have overseen a problem that we 
only catch while testing in Debian. Again, a versioned dependency can 
express what we find during unstable-to-testing integration.

Paul

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/debian-science-maintainers/attachments/20250412/1092beb9/attachment.sig>