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, andalready 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 slowdown 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