I observed today that many packages which can use MPI demand directly openpmi library instead of virtual/mpi (e.g. vtk, boost). So the question arises what is the reason for virtual/mpi if only one library for message passing have to be installed anyway. Actually this situation prevents us from using for example mpich2, because different MPI implementations block each other. Is this possible to demand in ebuilds for boost, vtk, etc. just virtual/mpi? If not let's remove it from potage just to not pretend we have a choice for MPI library. Reproducible: Always
*** Bug 309367 has been marked as a duplicate of this bug. ***
Not sure. Assigning to maintainers RDEPEND="|| ( sys-cluster/openmpi[cxx?,fortran?,romio?] sys-cluster/mpich2[cxx?,fortran?,romio?] sys-cluster/lam-mpi[fortran?,romio?] )"
(In reply to comment #0) > I observed today that many packages which can use MPI demand directly openpmi > library instead of virtual/mpi (e.g. vtk, boost). So the question arises what > is the reason for virtual/mpi if only one library for message passing have to > be installed anyway. Actually this situation prevents us from using for example > mpich2, because different MPI implementations block each other. > > Is this possible to demand in ebuilds for boost, vtk, etc. just virtual/mpi? If > not let's remove it from potage just to not pretend we have a choice for MPI > library. > It depends on both upstream and the maintainer. Testing against multiple mpi implementations is a hassle that both tend to skip. Also, lam-mpi is no longer actively developed and doesn't support some of the newer MPI extensions. If you are willing to help testing a package with other implementations and then filing a bug with your results would be helpful. This, of course, does require you to fix the deps in a local overlay first.
Closing as the original question appears to have been answered.
