RHEL 6.6 MPI mess

[Doug Ledford]

On Thu, 2014-10-30 at 11:14 -0400, Peter Martuccelli wrote:
> On Thu, 2014-10-30 at 14:27 +0000, Dave Love wrote:
> > The undocumented openmpi and mpich updates in RHEL6.6 have broken binary
> > compatibility and seem to be provoking general rebuilds of things in
> > EPEL.  While that may be OK for things that are packaged in EPEL, it at
> > best doesn't help with our HPC users' locally-built programs or
> > local/copr-published rpms (especially if the rebuilds involve their own
> > ABIs incompatibilities, like scalapack currently in testing).
> > 
> > It seems to me that the best approach, assuming Red Hat won't address
> > the issue, 
> Ledford, (Cc'd), may be able to offer some help.
> 
> Peter-
> > is to supply compatibility packages in EPEL if that will
> > work.  I haven't had a chance to try, but I'll probably have to make
> > something work eventually for openmpi, and presumably there are plenty
> > of people in a similar situation.  The updates are blocked by the
> > dependencies of many installed packages here, but it will be
> > increasingly awkward with packages that can't be updated without
> > rebuilds.
> > 
> > Has anyone tried that tack already, or is it clear it can't work for
> > some reason?

There was a changeover in maintainership for this package internally, so
I'm coming into this issue cold.  My apologies for that.  Have you
installed the compat-openmpi package and do things still break with that
installed (at least for openmpi, mpich is another matter entirely)?  If
so, then it seems we should have built a new compat-openmpi that kept
things working and that didn't happen.  The proper fix to this would be
to add the newer, missing libraries to compat-openmpi (assuming that's
possible...we may reach an incompatibility point in the compat-openmpi
package where newer libraries won't work with the runtime shipped in
this package as it currently uses a 1.4.3 runtime with 1.4.3 and 1.5.3
libs available IIRC).

The other alternative (although not a good one for EL6, but could be
used in EL7 and I believe is what's used in Fedora, although it's been a
long while since I help define the Fedora MPI policies so I could be
wrong) would be to make multiple versions of openmpi install side by
side without ever doing an upgrade.  Then newer openmpi releases would,
at most, change the default environment but leave the older environment
selectable via modules, allowing a user to simply select the old
environment and keep on running.

Anyway, that's where we stand on openmpi.  Someone will have to fill me
in on mpich.  I haven't done anything with mpich yet (it was added by
another employee, then transferred to me when that employee left the
company), so I will have to come up to speed.

Oh, and please leave me on the Cc: list.  Fedora-devel is a list I only
monitor occasionally.

-- 
Doug Ledford <dledford at redhat.com>
              GPG KeyID: 0E572FDD


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20141030/119ee187/attachment.sig>