On 2017-11-23 16:28, Alastair McKinstry wrote:
> There are three _implementations_ of the Process Management Interface
> (PMI): the Slurm one, the OpenMPI ("PMix") and the MPICH one. They are
> all expected to have the same ABI.
> Unlike jpeg, the three implementations will converge on the SOVERSION(s)
> as they are in the agreed ABI.
> Hence we will have differing behaviours with libraries with the same name.
Which is *not* the case now, as they have different SOVERSIONs currently
(slurm:0, pmix:1, mpich:?nosharedlib?), so you shouldn't use
alternatives to mix them *now*.
> Currently we have three possible 'users' of PMI: SLURM and the two MPI
> implementations, OpenMPI and MPICH.
> Each can be configured to use either its 'own' PMI or another; the
> libraries do the same thing but can have
> different implementation behaviours, (eg. MPICH calls its version
> 'simple' while PMIX from OpenMPI aims to scale well at ~10^6 processes).
>
> Its a realistic use case then to ship a simple PMI as default, but also
> allow another high-performance version to be available via alternatives,
> switchable at runtime.
In that case you would still only need one -dev package, that can be
used with the different implementations. Or does each one have different
"extensions" beyond the common API subset?
BTW, how do you plan to do library alternatives in multiarch? Keep them
in sync? How? or Why not?
Andreas
