Dave,
We chatted with Jeff today about this issue. Here's the summary.
The current GM OSCAR package (opkg) that grabs the latest greatest does
cause problems as you explained b/c that doesn't necessary (likely)
coincide with the version of GM that was used when LAM was built. And yes
this should be fixed.
However, the problem is that keeping opkg's (e.g., LAM) in synch with the
ever changing "latest" greated GM release is bad to say the least. The
discussions today centered around the idea of possibly offering better
support for building things from source, where "better" balances:
(a) Pkg authors: they don't have to rebuild their opkgs all the time,
whenever a new version of GM arrives on the website.
(b) Oscar users: they don't have to specify every detail about their
cluster and know the intimate details of how to make things work.
The proposed "ideas" include adding some sort of mechanisms that help to
support package authors building from source, and having the ability to
dynamically determine capabilities such that they can present the user with
"Configurator" options to the User. The user can then either accepts sane
defaults or click a few items and then the necessary steps are taken behind
the scenes such that things are build from source:
(a) in the proper order, i.e., GM build before LAM
(b) configured based upon the dynamic configuration information
(c) build (compiled)
(d) and possibly packaged for pkg mgmt, i.e., create RPM for OSCAR install
Another issue with this problem is that you need to have general dependency
information coming into this "Configurator" phase, and dynamic dependence
info coming out of this phase, ex.
(1) [POSSIBLE CONFIGS OPTS] LAM: gm, blcr, ib
(2) [SELECTED CONFIGS OPTS] LAM: gm
This is necessary so you can do the dependence checks before/after. This
all would have to work with the new "Package Set" idea we've been talking
about lately (this week).
So....there's really no solutions right now. Hopefully, this helps to
better characterize the problem. I'm not sure what we should do in the
short term but I do think we need better dependence information in the
oscar pkgs, possibly to include the actual oscar-version.
my $0.25,
--tjn
_________________________________________________________________________
Thomas Naughton [EMAIL PROTECTED]
Research Associate (865) 576-4184
On Fri, 21 Jan 2005, Lombard, David N wrote:
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
-------------------------------------------------------
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
