Well... I'm presently working on and OpenMPI ebuild that follows the belowmentionned path specs to be able to slot the MPI implementation as per: $implementation/$version/$compiler/
But I don't think this structure will change wether we use modules or eselect (we still need a separate place to store the mutually exclusive packages). But DO poke me if I am going in the wrong direction with this so that I don't waste too much time in the wrong direction. Thanks, Eric PS: couldn't eselect also work for a normal user...and just set the proper environment variable also....??...it's just a BASH script so we should be able to do it the "eselect" way ;) Le 12 Février 2006 18:33, Donnie Berkholz a écrit : > Andrew D. Fant wrote: > > I'll dig around and forward the ebuild to the list later tonight or > > tomorrow. At the risk of going off on a rant, I think that the > > /etc/env.d model is a core part of the problem. If two users want to > > use two different mpi implementations, will eselect allow them to both > > use them at the same time, or will it have to be one or the other at > > once? As I see it, something will have to be tweaking $LD_LIBRARY_PATH > > for each user's environment, > > Yep, that's the plan. Some things just won't work as well because they > don't really respect variables, like the includes. > > Something like this: > > MPI_IMPLEMENTATION="$implementation" > PATH="/usr/lib/mpi/$implementation/$version/$compiler/bin:$PATH" > LD_LIBRARY_PATH="/usr/lib/mpi/$implementation/$version/$compiler/lib:$LD_LIBRARY_PATH" > CPPFLAGS="-I/usr/lib/mpi/$implementation/$version/$compiler/include:$CPPFLAGS" > MANPATH="/usr/lib/mpi/$implementation/$version/$compiler/share/man:$MANPATH" > INFOPATH="/usr/lib/mpi/$implementation/$version/$compiler/share/info:$INFOPATH" > > > or /etc/ld.so.cache will have to be changed > > for each user's login to reflect their prefered mpi environment. > > That totally screws with multiple simultaneous logins. Environment > variables will have to be the way to go. > > > $PATH > > and $MANPATH can be handled by judicious checks in /etc/csh.cshrc and > > /etc/profile, but since /etc/env.d insists on manipulating the shared > > object cache directly, this has the potential to get really ugly without > > some cooperation from the core system team. I don't think that the > > cluster herd can fix it on it's own. > > I think we can, but I could certainly be proven wrong on this. > > > I would love to be proven wrong and will gladly defer to anyone who does > > so, I just know that I've been trying to outthink this problem for a > > year or so on our cluster and haven't come up with a sane solution for a > > true multi-user environment. > > I would love to find a way that works too. =) > > Thanks, > Donnie > > -- Eric Thibodeau Neural Bucket Solutions Inc. T. (514) 736-1436 C. (514) 710-0517 -- [email protected] mailing list
