[openfabrics-ewg] OFED-1.1-rc2 review comments: openib.spec

[Doug Ledford]

On Sun, 2006-08-27 at 13:24 -0400, Jeff Squyres wrote:

> Unfortunately, in the HPC arena, there are those who have strong religious
> preferences for one MPI or another.  There are both logical and
> irrational/religious reasons for individuals' preferences.  More
> specifically: whenever I've seen a large-scale HPC installation try to
> insist on just one MPI, the users rebelled.

Yeah, I kinda figured.....I'm just sooooo looking forward to that little
can of worms :-/

> > being said, we use the alternatives package to manage this.  My OpenMPI
> > package has to use this mechanism to work along side LAM (LAM was
> > pre-existing).
> 
> FWIW, we're trying to deprecate LAM/MPI (I was the LAM maintainer for many
> years).  LAM is great, but many of the features of Open MPI are far greater
> (although there's still a small number of features where LAM is superior,
> which is why we haven't actively killed it yet).  There is no OFED support
> for LAM (and never will be), for example.

Yeah.  The LAM support was part of Red Hat/Fedora since forever, it just
hasn't gone away yet.  Eventually it will.

> > Generally speaking, the alternatives setup is used like this:
> > 
> > 1. Make sure the binaries, etc. all have unique names.  If needed, the
> > typical --program-transform-name= ability of the configure scripts is
> > helpful.
> 
> This *may* be possible for Open MPI, but it'll require an audit.  I have a
> dim recollection of one of our developers saying a long time ago that this
> would be quite difficult for OMPI for some obscure reason...

Nah, wasn't hard.  The OpenMPI binaries are actually mostly links to
orte* binaries and ortewrapper.  So, just remove the links prior to
packaging.  It doesn't conflict on the main binary names much at all.

> I have no idea whether MVAPICH can do this or not.

It *should* be able to.
 
> > 2. Put the libraries (if there are any) in a directory that is not in
> > the library search path (such as /usr/lib/openmpi and /usr/lib/lam in my
> > case).  Ditto for devel files (/usr/include/openmpi
> > and /usr/include/lam).
> 
> This is probably do-able, but *may* require a little more than --libdir and
> --incdir options to configure (I *think* we did this stuff right, but I
> would need to check).

It worked.  They all went where they should.
 
> > 3. In the post and preun sections of the spec file, add/remove the
> > package to the alternatives setup.  This has to be coordinated between
> > the different packages in that they need to use the same link names and
> > master/slave setup.
> 
> Is there developer-level documentation about how the alternatives stuff
> works somewhere?

The man page on the alternatives program is pretty decent actually.

> > The reason we use the alternatives setup is that it allows for a default
> > order of selection based on priority, but should the user ever manually
> > select an alternative, that selection is kept by the system.  A little
> > later today I'll make my latest lam/openmpi packages available on my
> > infiniband upload area so people can look over the spec file to see what
> > I'm talking about if they wish.
> 
> Thanks; that'll be useful.
> 
> Did you use the LAM and/or Open MPI specfiles at least as a starting point?
> We actually have a fairly sophisticated specfile for Open MPI (can't
> remember what LAM does -- it's been a year or two since I've looked at it)
> based on requirements from a bunch of different groups.

The OpenMPI package had been put into our internal cvs by someone who is
no longer with Red Hat, and I inherited it from there.  I then redid a
reasonable portion of it, and I did reference the openmpi-1.1-1 spec
that was in an earlier OFED 1.1 rc when doing the work.  But, I couldn't
tell you how much of your particular setups I might have preserved,
you'd just need to look through my spec file and see if I kept the
things you need.

I'm syncing my latest user space rpms to web page right now so you can
take a look whenever you want.

-- 
Doug Ledford <dledford at redhat.com>
              GPG KeyID: CFBFF194
              http://people.redhat.com/dledford

Infiniband specific RPMs available at
              http://people.redhat.com/dledford/Infiniband
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.openfabrics.org/pipermail/ewg/attachments/20060827/31d4a478/attachment.sig>