[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: building package with different libs



[ Sorry for the long email! I wanted to express my view and as a
non-native speaker, it's not always easy to be precise. Hope you don't
mind. ]

Am Dienstag, den 18.11.2008, 08:05 -0500 schrieb 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:
> > | 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.

It's hard to say at the moment because I do not have all the details
yet. Personally, I'd like to have support on all arches before the
release of Squeeze, I hope around summer next year, though this might be
a bit optimistic. I'm currently in the process of getting details about
what is and what needs to be done; not just with getting OpenMPI to
build on all arches, but how we can handle the other open issues with
mixing different MPI implementations.

What we have so far: We have an untested patch to make OpenMPI build on
MIPS. It did not apply to the current upstream version and I lately
tried to update it to the current upstream release. I asked for feedback
but did not get any so far. (I guess I'll try to build OpenMPI on a MIPS
as soon as I have some spare cycles.) We also have a patch that makes
use of libatomic-ops on currently unsupported architectures. It is not
well tested and may have some itches we need to scratch but it may be
enough to get OpenMPI to run on all arches. Thanks to everyone involved
in providing patches and solutions so far! It is very much appreciated.

So, the honest answer is: I do not have a clue. As said, I'm working on
it and it is one of the most important things in my Debian work at the
moment. But we heavily rely on the porters, need testing and need to get
all MPI maintainers together to sort some other issues out. This takes
time. Nevertheless, I'm optimistic that we can sort this out before
Squeeze, including the transitions.

I do not oppose to an mpi-default-dev package, I thought of that myself
as well. Nevertheless, I also think we can sort that out in time and
live with the situation as is until then. I will not stop anyone from
implementing it, though. It might assist developers a lot and is surely
a Good Thing. But it's just a part of the problem. I also think that a
huge part of the problem is that MPI maintainers did not talk to each
other so far; at least such efforts are not known to me. OpenMPI did not
see much love in Debian for quite some time and we just started to get
it back on track. We now have a well working team (Thanks, dudes!) and
that's why I'm optimistic that we can now do the next steps and join the
efforts of everyone involved in MPI maintainance in Debian.

I would suggest that I collect some more information, write it up and we
discuss things then, so we can agree which road is the best to take. (I
do not know where the appropriate place for that is, though.) I can't
promise anything but hope to have that finished within the next two
weeks. Does this sound acceptable?

> > 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.

We should IMHO base that decision on the fact which MPI implementation
is the "best". We need to decide on supported arches as well as other
factors, and I do not have the full picture yet. (If anyone else has,
please get in touch with me!) I'd suggest to not change the priority as
of now. Even with my OpenMPI maintainer had on, I'm not yet convinced
that OpenMPI is the most sensible default.

Best regards
Manuel

Attachment: signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil


Reply to: