Bug 20654 – LAM-MPI should be in "sys-cluster/" category

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Jean-François Richard 2003-05-08 17:21:23 UTC]

The LAM-MPI package is definitely a clustering application and should be placed
in the sys-cluster/ category.  MPICH is already there, all implementations of
MPI should also...

I was surprised to find it there while working on Adelie Linux on a HPC Cluster.

Reproducible: Always
Steps to Reproduce:

[Comment 1 Michael Imhof (RETIRED) 2003-05-10 07:43:43 UTC]

I'm reassigning this bug to George as he maintains lam-mpi.

George, could you move lam-mpi to sys-cluster?

[Comment 2 George Shapovalov (RETIRED) 2003-05-12 03:17:10 UTC]

Ok, upon investigating the situation I decided to hold-off the move until >=portage-2.0.48 gets unmasked.
The reason:
At present I would have to add PROVIDE="sys-claster/lam-mpi" to all ebuilds. However this PROVIDE only gets picked up when the package is merged. Thus all the users who have lam-mpi up already will get a broken system or at least some trouble during their next emerge --update world (which they should do with --pretend of course).
While the impact may be minor for the "top-level" package, it may cause grave consequences when a core lib on which some production clusters depend is moved.

portage-2.0.48 on the other hand will allow to move packages "transparently", so such breakage is avoided.
Therefore, while it is possible to find ways around, I think it is best to hold off the move until portage-2.0.48 gets into stable, which, according to carpaski, should be RSN (it should get into testing fithin few days btw).

Jean-Fran

[Comment 3 George Shapovalov (RETIRED) 2003-05-12 03:17:10 UTC]

Ok, upon investigating the situation I decided to hold-off the move until >=portage-2.0.48 gets unmasked.
The reason:
At present I would have to add PROVIDE="sys-claster/lam-mpi" to all ebuilds. However this PROVIDE only gets picked up when the package is merged. Thus all the users who have lam-mpi up already will get a broken system or at least some trouble during their next emerge --update world (which they should do with --pretend of course).
While the impact may be minor for the "top-level" package, it may cause grave consequences when a core lib on which some production clusters depend is moved.

portage-2.0.48 on the other hand will allow to move packages "transparently", so such breakage is avoided.
Therefore, while it is possible to find ways around, I think it is best to hold off the move until portage-2.0.48 gets into stable, which, according to carpaski, should be RSN (it should get into testing fithin few days btw).

Jean-François: I am closing this bug with "LATER" for now, please reopen it when described condisions are matched.

George

[Comment 4 Michael Imhof (RETIRED) 2003-05-12 18:40:01 UTC]

George: Sounds good to me!

[Comment 5 George Shapovalov (RETIRED) 2003-06-19 12:14:04 UTC]

portage-2.0.48 is stable, reopening the bug.

[Comment 6 George Shapovalov (RETIRED) 2003-07-07 23:00:41 UTC]

Moved, registered under profiles/updates/2Q2003,
added PROVIDE to lam-mpi and adjusted DEPEND in two dependants (fftw and gromacs) :).
Please check.

George

[Comment 7 Olivier Crete (RETIRED) 2003-12-08 15:36:40 UTC]

has been fixed long time ago