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:
I'm reassigning this bug to George as he maintains lam-mpi. George, could you move lam-mpi to sys-cluster?
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
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
George: Sounds good to me!
portage-2.0.48 is stable, reopening the bug.
Moved, registered under profiles/updates/2Q2003, added PROVIDE to lam-mpi and adjusted DEPEND in two dependants (fftw and gromacs) :). Please check. George
has been fixed long time ago
