Bug#998411: Bug#996204: transition: numerical library stack: hypre SONAME (Policy 8.1)

[Drew Parsons]

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 reverse
> dependencies, therefore breaking smooth updates of the packages 
> involved
> in 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