packaging mpich2 -- conflicts with lam and file layoutb

[Paul Howarth]

On Tue, 2005-11-08 at 13:14 -0500, Ed Hill wrote:
> 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 ...?

There's nothing stopping manpages (or anything else really) using the
alternatives system. The sendmail package includes some manpages done
this way,

Paul.
-- 
Paul Howarth <paul at city-fan.org>