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

[Sebastian Ramacher]

On 2021-11-03 22:33:01 +0100, Drew Parsons wrote:
> 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).

(So why is this packaged as shared library?)

> 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.

That's why the second sentence of 8.1 reads: "This allows several
versions of the shared library to be installed at the same time,
allowing installation of the new version of the shared library without
immediately breaking binaries that depend on the old version."

The problem is not deal.ii.

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

deal.ii doesn't FTBFS. deal.ii cannot currently be rebuilt in unsable
because of another broken shared library (#995424 in gmsh). Once deal.ii
is rebuilt (in testing), #996277 will disappear.

> 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

It won't be removed.

> 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?

Yes. Having to wait for binNEW to being processed is not an excuse to
violate a must section of the policy.

Processing of packages in NEW can take some time. I'm also waiting on
some of them for months. The solution to that is however not to abondon
well established practices for shared libraries. The problems that are
caused by that can be seen with libhypre and its reverse dependencies.

Cheers
-- 
Sebastian Ramacher