Bug#940595: transition: hypre
On 17/10/2019 17:05, Drew Parsons wrote:
> 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.
Right, the strict dependency via shlibs and provides would make testing
migrations harder as everything would need to transition at the same time (hypre
and all rdeps). However there are three rdeps and you control two of them, so it
doesn't look like a terrible situation.
OTOH bumping the package name (if that's what upstream does with the SONAME) is
probably preferable despite the NEW roundtrip.
Another option would be for you to review the changes in point releases and
assess whether there is an ABI break or not, and avoid bumping the shlibs /
provides in that case. In fact you could mix the two, shipping e.g.
libhypre-2.18 with Provides: hypre-abi-2.18.0, and strict dependencies on that
for rdeps. Then if you update to 2.18.1 and there's no ABI break, you don't
change that.
But that may be overcomplicating things for a package with so few rdeps.
Cheers,
Emilio
Reply to: