[ 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