1 |
Well bug 44132 [1] has been a real thorn in my side for some time. The |
2 |
problem being that all mpi implementations currently in portage block each |
3 |
other. This is a real pain for any serious administrators, makes testing |
4 |
new/other implementations too time-consuming, and in my opinion has probably |
5 |
slowed any progress related to getting cluster applications into portage or |
6 |
the overlays. |
7 |
|
8 |
All that being said, I set out to do something about it. Donnie Berkholz was |
9 |
nice enough to help me out early on and ended up suggesting that I look |
10 |
at crossdev. I shamelessly ripped off the aforementioned script and tuned |
11 |
it for mpi implementations and packages. It should be noted that all the |
12 |
changes I've implemented do [should, hopefully will] not effect the way the |
13 |
packages behave now, rather it just adds another option. The idea is as |
14 |
follows. |
15 |
|
16 |
sys-cluster/empi: Does the same stuff that crossdev does. You create a new |
17 |
implementation root by specifying a name and mpi implementation package to |
18 |
build it with. [2] Empi adds these to an overlay under a new category with |
19 |
the name you gave. The ebuilds inherit mpi.eclass which handles pushing all |
20 |
the files to /usr/lib/mpi/<name>, and providing files for eselect-mpi. |
21 |
|
22 |
Later, you can add packages by specifying the category name and packages to |
23 |
install. Empi grabs the ones that inherit mpi (including deps), adds them to |
24 |
the overlay and emerges. The deps stuff hasn't been tested all that much. |
25 |
|
26 |
app-admin/eselect-mpi: Used to setup a user's environment to call a named |
27 |
implementation install. Basically does this by dropping a bash-sourceable |
28 |
file in ${HOME}/.env.d/mpi. The not-so-fun part is that the user then has to |
29 |
remember to source that file. Also used a fair amount by mpi.eclass. |
30 |
|
31 |
I threw some quick notes showing commands and output up in my devspace. [3] |
32 |
If anyone is at all interested, please try this out and let me know what you |
33 |
think. Even if you don't try it out but have ideas/comments/rants, I'm all ears. |
34 |
|
35 |
Current overlay has the following ready to be tried out. |
36 |
eselect-mpi/eselect-mpi-0.0.1 |
37 |
sys-cluster/empi-0.1 |
38 |
sys-cluster/hpl-1.0-r3 |
39 |
sys-cluster/lam-mpi-7.1.4-r1 |
40 |
sys-cluster/mpi-examples-1.0 |
41 |
sys-cluster/openmpi-1.2.5-r1 |
42 |
|
43 |
A couple of final words, hpl and mpi-examples currently wouldn't work without |
44 |
empi, mainly because I'm lazy :) Also I still haven't figured out a good way |
45 |
to handle do{man,doc,www} etcetera, ideas are welcome. There's still a fair |
46 |
amount of work to be done, but I wanted to see if anyone had any feedback |
47 |
regarding the general concept first before pushing on. |
48 |
|
49 |
You can pull the overlay from rsync://cold-front.ath.cx/mpi (for now...) |
50 |
|
51 |
Thanks, |
52 |
|
53 |
|
54 |
[1] http://bugs.gentoo.org/show_bug.cgi?id=44132 |
55 |
[2] Currently openmpi-1.2.5-r1 or lam-mpi-7.1.4-r1 |
56 |
[3] http://dev.gentoo.org/~jsbronder/README.empi.txt |
57 |
|
58 |
-- |
59 |
Justin Bronder |