packaging mpich2 -- conflicts with lam and file layoutb

Ed Hill ed at eh3.com
Tue Nov 8 18:14:37 UTC 2005


On Tue, 2005-11-08 at 18:37 +0100, Enrico Scholz wrote: 
> ed at eh3.com (Ed Hill) writes:
> 
> > I want multiple MPI implementations installed side-by-side and I
> > want to select, for instance, which "mpirun" is called on a ***
> > per-session basis *** by either specifying its full path or by using
> > some semi-automated ${PATH} manipulation magic such as:
> > ...
> > So, my question for the packaging-gurus becomes:  Is there some way that
> > we can accomplish that using something like (that is, similar but
> > perhaps not exactly the same as):
> >
> >   /usr/lib/${MPI_IMPL_NAME}/{bin,man,lib,include}
> 
> You could create binaries like
> 
> | /usr/bin/lam-mpiCC
> | /usr/bin/mpich2-mpiCC
> 
> These binaries are settings correct $PATHs (resp. this should not be
> needed when the packages are configured with correct paths).
> 
> In simplest case, the binaries are sym- or hardlinks like
> 
> /usr/bin/mpich2-mpiCC -> ../lib/mpich2/bin/mpiCC


Hi Enrico & Jeff,

Thanks for the comments!  I suppose the above linking scheme is the best
that can be done for binaries.  While it is somewhat annoying, it does
allow the binaries for multiple MPI implementations to co-exist which is
sufficient for side-by-side installs.  Good enough for me.  ;-)

So, that leaves one issue -- what should be done about the man pages?
The different MPI implementations have different man pages not only for
the binaries but also for much of the MPI API (all the functions which
obviously have the same names across implementations).  Can the man
pages be somehow renamed and/or relocated?  Or should they be converted
to html pages or totally ignored or ...?

Ed


-- 
Edward H. Hill III, PhD
office:  MIT Dept. of EAPS;  Rm 54-1424;  77 Massachusetts Ave.
             Cambridge, MA 02139-4307
emails:  eh3 at mit.edu                ed at eh3.com
URLs:    http://web.mit.edu/eh3/    http://eh3.com/
phone:   617-253-0098
fax:     617-253-4464




More information about the fedora-extras-list mailing list