On 2021-11-04 21:41, Sebastian Ramacher wrote:
On 2021-11-03 22:33:01 +0100, Drew Parsons wrote:
...
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?)
A reasonable question to ask. For my part, it was already being
packaged as a shared library when I started working on it, so I just
continued it so. I could imagine a clash of hypre symbols if a client
programs links against both petsc and sundials (which both use hypre),
and uses hypre directly. I guess the symbol table must guard against
clashes like that.
...
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.
Fair enough. I'll make the change, either to libhypre2.22.2 or to
libhypre-static.
Drew
