Hi Drew, On Fri, 11 Apr 2025 12:23:45 +0200 Drew Parsons <dpars...@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
OpenPGP_signature.asc
Description: OpenPGP digital signature
