On 2021-11-03 20:57, Sebastian Ramacher wrote:
Source: hypre Severity: serious
...
The real blocker is hypre, specifically: hypre (2.18.1-1) experimental; urgency=medium . * Team upload. * New upstream release. * Standards-Version: 4.4.1 * Provide library binary package as libhypre without the soname version embedded in the package name. Enforce version dependency through strict shlibs dependency. This is to workaround lack of ABI backwards compatibility and keep minor version updates being delayed in the NEW queue. See README.Debian. As a consequence, hypre breaks co-installability of all its reversedependencies, therefore breaking smooth updates of the packages involvedin the transition. And yes, in the end, deal.ii currently keeps the whole stack from migrating as it renders deal.ii's binaries uninstallable in testing.
The problem that hypre 2.18.1-1 (un-versioned libhypre) intended to solve is that hypre is ABI-ignorant (https://github.com/hypre-space/hypre/issues/56), so each point patch release would have to be a new binary package, and the upstream release rate is faster than the average NEW queue processing rate (the new package for the current transition would be libhypre2.22.1, and already libhypre2.23.0 is released upstream).
hypre has only 2 direct reverse dependencies, petsc and sundials, which we can keep up-to-date easily. The current problem is that deal.ii depends on the old petsc3.14, so it can't be installed with the new petsc3.15. It wouldn't be a problem in practice, if deal.ii hadn't started FTBFS (Bug#996277) preventing it rebuilding against petsc 3.15. We could say it was tactical error running the hypre and petsc ABI updates at the same time (I wasn't anticipating deal.ii Bug#996277)
If we revert back to version-named hypre library packages then the cost is that we won't be able to provide timely patch updates for hypre (each one will be a new library package needing to pass NEW, since hypre does not provide ABI compatibility).
The alternative for this transition is to remove deal.ii from testing, which is happening anyway due to Bug#996277
So the use of un-versioned libhypre was intended as a specific exception to Policy 8.1, for the purpose of facilitating faster hypre patch updates. The irregularity is due to a lack of ABI-awareness in hypre itself.
Is it best to revert back to strict Policy 8.1 compliance, which will slow down hypre patch release updates?
Drew