Having a broken package is far worse than having no package at all. So, my understanding is that the current OSCAR GM package on OPD will legally and properly download the latest GM from Myricom and build it properly for the system; the problem being that LAM was built for a different GM, and is not expected to work with the latest GM. Is this correct?
Is the correct GM available now? If so, can we communicate this requirement to the OSCAR GM package? If we do, will that resolve the problem? At least for as long as Myricom hosts the correct GM? If not, perhaps we're making a mistake to consider GM now, especially when we consider IB. -- David N. Lombard My comments represent my opinions, not those of Intel Corporation. >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:oscar-devel- >[EMAIL PROTECTED] On Behalf Of Jeff Squyres >Sent: Friday, January 21, 2005 9:37 AM >To: OSCAR-devel >Subject: [Oscar-devel] The Problem With GM > >So I'm replying but giving this another subject because this is a >tangent... > >What do we want to do about GM? It's actually a problem -- nothing can >use GM right now, as it stands. > >The GM package is downloadable off OPD, and thanks to efforts from >Jeremy Enos, it does everything legally -- it pops open a window for >the username and password on the Myricom FTP site. Once you enter >those, it gets the latest GM source tarball, compiles it, and installs >it. > >However, the GM that LAM was compiled with will almost certainly be a >different version (it is now, for certain -- the latest gm in the 2.0.x >series is 2.0.17), thereby making it unusable. I don't know how other >packages are bundled that use GM, but unless they're updated frequently >(which I know they're not), they'll suffer from the same problem. > >So the issue is that we *don't* have a fixed version of GM, but all the >packages that use it will require a fixed version (because things >change in each release of GM). > >Suggestions? > > >On Jan 21, 2005, at 12:31 PM, Lombard, David N wrote: > >> I've attached a binary rpm audit of the trunk. >> >> Various conventions are used to partition distro-specific packages. >> Should we make this consistent? >> >> Package-specific comments: >> >> c3 >> -python2 for i386? >> >> hdf5 >> -Huh? >> -mdk90 >> >> lam >> -ia64 in rh90? >> -gm only for rh90/i386? >> >> maui >> -extra maui-oscar-debuginfo >> >> mpich >> -ia64 in rh80? >> -mdk90? >> >> openpbs >> -missing ia64. Do we care? >> >> perl-qt >> -no distro-specific dirs? >> -libsmokeqt1? >> >> pvm >> -mkd90? >> -mdk92? >> >> sis >> -inconsistent versions >> >> switcher >> -env-switcher only in fedora2? >> -mkd90? >> -mdk92? >> >> -- >> David N. Lombard >> >> My comments represent my opinions, not those of Intel Corporation. >> <rpm-audit.txt> > >-- >{+} Jeff Squyres >{+} [EMAIL PROTECTED] >{+} http://www.lam-mpi.org/ > > > >------------------------------------------------------- >This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting >Tool for open source databases. Create drag-&-drop reports. Save time >by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. >Download a FREE copy at http://www.intelliview.com/go/osdn_nl >_______________________________________________ >Oscar-devel mailing list >[email protected] >https://lists.sourceforge.net/lists/listinfo/oscar-devel ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Oscar-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oscar-devel
