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

[Drew Parsons]

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