[Pkg-openmpi-maintainers] building package with different libs

[Adam C Powell IV]

On Sat, 2008-11-15 at 21:04 -0600, Dirk Eddelbuettel wrote:
> On 14 November 2008 at 23:12, Steve M. Robbins wrote:
> | Howdy,
> | 
> | 
> | On Thu, Oct 30, 2008 at 07:48:19PM -0400, Adam C Powell IV wrote:
> | > [Copying -beowulf as there's likely some interest there as well.]
> | > 
> | > On Thu, 2008-10-30 at 15:21 +0100, Manuel Prinz wrote:
> | 
> | > > When building against OpenMPI, there are a few choices:
> | > > 
> | > >  1. Do not build packages using OpenMPI on the unsupported arches.
> | > >  2. Build against OpenMPI on the supported ones, fall back to LAM on the
> | > > unsupported ones.
> | 
> |     [ ... ]
> | 
> | > As for -lam where there's no openmpi, I only know of petsc and babel.
> 
> [ For r-cran-rmpi, I also fall back to using LAM where Open MPI is
> missing. Perusing NEW today, I saw that Adam falls back to MPICH for the new
> Arpack. May be a better fall-back, but I personally have used LAM and no
> MPICH before Open MPI. I guess at some point we need to consolidate out MPI
> efforts. ]
>  
> | I have subsequently adopted this approach for minc, which uses MPI via
> | hdf5.  I will likely adopt it for boost, too, unless someone has a
> | better idea.
> | 
> | While reading this thread, however, I had an idle thought.  Could we
> | prepare an "mpi-default-dev" or "sensible-mpi-dev" package for us to
> | build-depend on?  This would be something like the gcc-defaults
> | package and simply depend on the appropriate -dev pacakges (OpenMPI on
> | some architectures, LAM on the rest).
> | 
> | The idea is to put the messy details about which architectures support
> | OpenMPI and which use LAM in one place.
> 
> Sounds good to me, and I am cc'ing the pkg-openmpi list. I won't have spare
> cycles to work on it, but it strikes as a fundamentally sound suggestion.

I'm all set to make this happen.

Manuel, you mentioned getting OpenMPI to work on all arches as your top
priority; what's your expected timeframe?  I know, "when it's ready" or
"real soon now".  But if this will happen in plenty of time for packages
to transition before squeeze, then there's no point in doing
mpi-defaults.

> And while we're at it, it may also make sense to try to come to a consensus
> of our MPI 'preferences' within Debian. I.e. which one should be the default
> and own the 'highest' alternatives level.

Good point.  I'm happy to change mpich to below the priority of OpenMPI,
maybe the same as lam?  And within mpich, ch_p4 is the "default" but
should be below ch_p4mpd (if you install mpd then you're probably
running the daemons); I'll put ch_shmem between them.

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.alioth.debian.org/pipermail/pkg-openmpi-maintainers/attachments/20081118/b2bee9db/attachment.pgp