Packaging question on MPI requires

[Dave Love]

Zbigniew Jędrzejewski-Szmek <zbyszek at in.waw.pl> writes:

>> What are you supposed to do with MPI packaging for another language such
>> as R?  By the sound of it
>> <https://copr.fedoraproject.org/coprs/loveshack/livhpc/package/R-pbdMPI/>
>> and friends will fail now.
> As a short-term solution, it is always possible to skip automatic
> generation of Requires, and add whatever is necessary by hand.
> In the long run, packaging should be changed to be similar to Python:
> 1. an MPI-implementation specific directory should be used for R modules
> 2. the dependency generator should be taught to scan this directory

Surely this isn't scalable.  What would happen with a common API for N
different Scheme implementations, for instance?  I'm also interested in
Haskell; others might want the bindings to Common Lisp, ruby, Tcl...
Currently CLASSPATH isn't set for the Java bindings.  At least I'd have
thought there needs to be some sort of hook for extensibility.

This is the sort of reason I think the rules for MPI packaging are
unfortunate.

> The situation for R is a bit simpler, because (afaik) only one version
> of R is packaged in the distrubution.
>
> Note that currently, /usr/lib64/R/library/pbdMPI/libs/pbdMPI.so from R-pbdMPI
> only works with one MPI implementation, but Fedora has two, and support
> others, and the module cannot be made to work with both while installed
> in this location.

Of course.  I assumed only being able to support one meant it wasn't
worth trying to get R-pdb through review, even though some existing
packaging doesn't support mpich.  I'm only interested in open-mpi --
possibly mvapich in some cases -- on EPEL-based systems, but I shared
the packaging so anyone could rebuild it locally.