Bug#1147135: prrte: libprrte3 checks the version of pmix, does it need an upper limit or the check removed?

[Drew Parsons]

Source: prrte
Followup-For: Bug #1147135

Alastair is the main boss for the package,
but reviewing the code, I think prrte has been fixed upstream in v5.

The current version check in src/runtime/prte_init.c
at https://salsa.debian.org/science-team/prrte/-/blob/debian/latest/src/runtime/prte_init.c#L145
passes on 

   if (major > limmajor)
(referring to the pmix versions, runtime vs buildtime)

If I'm reading it correctly it means future pmix v8 will pass with
prrte built against the current pmix v7.

The problem is that old prrte v3 in testing doesn't have the update,
so current pmix v7 is failing against old pmix v5.

So I think think "going forward" we won't continually repeat the
problem, but we have an impasse right now updating prrte v3 to v5.

It looks like the simplest workaround
(apart from simply manually forcing the current pmix/prrte update)
might be to have

libpmix2t64 Breaks: libprrte4 (<< 5~)



At the same time, the identity of the binary package libprrte4 is
discrepant.  The library is libprrte.so.5,
which suggests the package name should be libprrte5.
These packages should be upgrade via an ABI transition,
and the prrte library package should be libprrte4 not libprrte5.

However this last point is a separate issue from the pmix version
check (the old prrte is libprrte3 not libprrte4, so it's already not
clashing as far as the prrte binary files go).

Drew