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

[Manuel Prinz]

[ CCs removed ]

> On Tue, 2008-11-18 at 22:25 -0600, Dirk Eddelbuettel wrote:
> > On 18 November 2008 at 23:03, Adam C Powell IV wrote:
> > | All things considered, OpenMPI has my vote as the most advanced
> > | implementation right now...
> > [some arguing] so we get
> >    
> >         Open MPI > MPICH > LAM
> > 
> > in reverse alphabetical order. How cute :)  
> > 

This would be my perferred order as well.

> Manuel, what were your thoughts against Open MPI as the default?  Lack
> of availability on all arches?  "Newness" ?

Supported architectures is of course something we should consider. Open
MPI being "new" is not that much of an issue, it has proven to be very
reliable. But I think we should also keep things like "active upstream"
in mind, which Open MPI just rocks at. ;)

IMHO the arch support is quite a show-stopper, unfortunately. And I do
not have good numbers on the size of the user base yet. Popcon is IMHO
too biased under the current circumstances.

Am Dienstag, den 18.11.2008, 21:07 -0800 schrieb Ross Boylan:
> It sounds as if the appropriate default package may vary by
> architecture; one of the beauties of the proposal to have one MPI
> metapackage is that it can centralize that mess.

Yes, but it only helps if our use case is to build a package that uses
MPI just against the default implementation. Debian users are therefore
forced to install our default and rebuild against the MPI implementation
that they prefer.

Some packages build a seperate package for each MPI implementation. That
is something that IMHO can't be handled by introducing a meta-package
easily.

So we should think about whether we just want to build one MPI-using
package for the default implementation or one package for each MPI
implementation in Debian. The later one is more work on our side but
probably better from a user perspective. The former should be pretty
easy to do once a meta-package exists. (It's more or less recompiling.)
I have not set my mind on what's reasonable here yet.

> Can the alternatives priorities also vary by architecture?  If not,
> there could be an odd situation in which the default package might not
> be the highest priority.  I'm not sure the alternative mechanism is
> necessary in this case, or even if that's what the ordering was
> addressing.

AFAIK they can't vary by architecture but that should not be too much of
a problem, since the "default" one (Open MPI) is simply not available,
so MPICH would be the one with the highest priority on the architectures
that Open MPI does not support.

Best regards
Manuel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://lists.alioth.debian.org/pipermail/pkg-openmpi-maintainers/attachments/20081119/3279be8b/attachment-0001.pgp