On 26/02/08 09:44 -0800, Donnie Berkholz wrote: > On 10:45 Tue 26 Feb , Justin Bronder wrote: > > I've been spending the majority of my Gentoo-related time working on a > > solution to bug 44132 [1], basically, trying to find a way to gracefully > > handle multiple installs of various MPI implementations at the same time in > > Gentoo. Theres more information about the solution in my devspace [2], but > > a quick summary is that there is a new package (empi) that is much like > > crossdev, a new eselect module for empi, and a new eclass that handles both > > mpi implementations and packages depending on mpi. > > Is it enough like crossdev enough to share code, with perhaps a bit of > abstraction? Maintaining the same thing twice is rarely a good idea...
They are similar in that they both use the same finagling with portage to install things to different locations, but it pretty much ends there. So far as sharing code, I can see maybe the symlink, portdir and /etc/portage stuff that might be shared. Given that crossdev is ~650 lines and empi is half that though, I'm of the opinion that it's not worth the effort. The majority of the work in empi is reading command line arguments and testing to make sure preconditions are met. > > > So, I think I have pushed this work far enough along for it to actually be > > somewhat officially offered. My question then, is where should this be > > located? There are several mpi packages in the science overlay already, so > > should I push this work to there, or would it be more appropriate to make a > > new overlay specifically for hp-cluster? > > > > Future work related to this project will be getting all mpi implementations > > and dependant packages converted in the same overlay before bringing it up > > on > > -dev for discussion about inclusion into the main tree. > > > > I have no real preference either way, but the science team does already have > > an overlay :) Let me know what you think. > > Seems like people already committing cluster stuff to the sci overlay > could help; maybe they'll port packages, fix bugs, etc. With a new > overlay, we'd have to start from scratch, and I don't really see the > point. Pretty much sums up why I'm posting here :) -- Justin Bronder
pgpsgeICUvffF.pgp
Description: PGP signature
