[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#940595: transition: hypre



Control: tags -1 - confirmed

On 2019-10-17 15:23, Emilio Pozuelo Monfort wrote:
Control: tags -1 confirmed

On 17/10/2019 05:53, Drew Parsons wrote:
On 2019-10-12 22:19, Emilio Pozuelo Monfort wrote:
On 12/10/2019 16:08, Drew Parsons wrote:

Thanks Emilio.  2.18.0 is now released, and waiting now in the new queue. Perhaps we should hold on a bit and jump straight to 2.18.0.  That will save
having to process 2 transitions. What do you think?

Sure, that makes sense. Let us know once things are ready for 2.18.

hypre 2.18 is accepted now and built in experimental already.  petsc seems to perform fine with the new version and sundials builds successfully.  Let's
proceed with the transition.

Ack.


Hi Emilio, this is rather awkward. Hypre upstream has just released 2.18.1, so this would be the one to run the transition on.

The particular awkwardness is that upstream does not believe in shared libraries, and therefore does not maintain ABI compatibility even in patch releases. I asked explicitly about it, https://github.com/hypre-space/hypre/issues/56, and so they've added a comment to their documentation:

"The hypre team currently does nothing to ensure application binary interface (ABI) compatibility. As a result, all releases (major, minor, or patch) should be treated as incompatible."

It means we have to run a new library package for each patch release, and therefore have to jump back into the NEW queue with libhypre-2.18.1. It's either that, or provide only a generic libhypre package and apply rigidly strict shlib files depending strictly on a given version.

I'd be interested to hear which option you think is best. A strict shlibs dependency with a generic ABI-free package name would save having to traverse the NEW queue each time but would be a little brutal on testing migrations and general archive robustness.

I've preemptively de-confirmed the transition.

Drew


Reply to: