On 2019-10-18 15:56, Emilio Pozuelo Monfort wrote:
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.
Thanks for the options, Emilio. Tracking ABI changes manually sounds
like a recipe for disaster, especially if upstream is promising to be
capricious with ABI changes. Given the small number of rdeps, the
strict shlibs might prove less painful than putting up with the NEW
queue wait. Normally the new versions don't happen so often, upstream
has just been a bit busier than usual the last month or two. I'll have a
think on it a little then choose one option or the other. Would need to
jump into NEW queue anyway to get the libhypre shlibs option started.
Drew
