On 23/11/2017 13:33, Andreas Beckmann wrote:
> Luckily we have a limited number of users:
>
> libpmix2
> Reverse Depends:
> libpmix-dev
> libopenmpi3
> libpmi2-0
> Reverse Depends:
> libpmi2-0-dev
>
> There are no users (B-D) for libpmi2-0-dev
>
> So slurm itself isn't even using the library it provides, therefore
> maybe it would be the easiest to just drop it from the slurm packaging?
>
> And we can continue discussion once a potential user for the old version
> from slurm comes up ...
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.
> On 2017-11-23 09:22, Gennaro Oliva wrote:
>> On Wed, Nov 22, 2017 at 10:20:17AM +0000, Alastair McKinstry wrote:
>>> Yes, this would be my preferred solution. Shipping:
>>> libpmi-pmix-dev
>>> libpmi-slurm-dev
> Is slurm shipping a "modified" version compared to the "official"
> release? In that case this naming would make sense. Otherwise
> distinguish them by an API version (or SOVERSION).
>
>>> and then providing alternatives.
>> great! Shouldn't we provide alternatives for the library package too?
> Please stop this insanity now!
>
> *** No alternatives for shared libraries. ***
> *** No alternatives for .so links. ***
>
> I think the best case comparable to yours is libjpeg.so
> In sid we have three packages shipping this file, but only one can be
> installed at a time.
> But libjpeg62-turbo and libjpeg9 can be installed at the same time.
>
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.
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 no way libpmi2.so.0 can be used as a replacement for libpmi2.so.1
> (and vice versa), otherwise there shouldn't have been a SOVERSION bump.
>
> It's nice to have consistent naming ...
>
> The command from the policy [8.1] suggests these package names:
> libpmi2-0, libpmi2-1
I'd agree with those names, if we weren't expecting alternatives.
> [8.1] https://www.debian.org/doc/debian-policy/#run-time-shared-libraries
>
> The -dev packages providing the same .so link need to conflict with each
> other. And at most one of them may use the "generic" name "libpmi2-dev"
> (or Provides: libpmi2-dev).
>
>
> Andreas
>
> PS: I have no clue at all what these libraries are about ...
Best regards
Alastair
--
Alastair McKinstry, <alast...@sceal.ie>, <mckins...@debian.org>,
https://diaspora.sceal.ie/u/amckinstry
Commander Vimes didn’t like the phrase “The innocent have nothing to fear,”
believing the innocent had everything to fear, mostly from the guilty but in
the longer term
even more from those who say things like “The innocent have nothing to fear.”
- T. Pratchett, Snuff
