On Oct 9, 2007, at 4:07 PM, Edgar Gabriel wrote:
One of my big problems with this idea is that we lose the concept of
shipping a single unit of Open MPI. If someone sends us a bug report
concerning VT, we no longer have a solid idea of what version they
are running because they may have replaced the one inside their Open
MPI software.
well, this issue could be however resolved, if ompi_info and friends
would have a way to report the precise version number for VT, isn't
it?
I don't quite know how to do it yet, but I agree that ompi_info
should show the following for each 3rd party package:
- whether we are using the internally bundled package or not
- the version of the internally bundled package
I'll muck around with the libnbc integration to figure this stuff out.
Without having any strong feelings one way or the other, I think that
the functionality is great from the end-users perspective. Just my
0.02$...
It makes me very, very nervous. When we ship Open MPI, we test it
and have a good feel for what works and what does not. If a user
changes something inside their installed Open MPI, all bets are off
on whether it will work or not. Some users will get it right, some
will not (so you have to assume that they will not).
I think it is far safer to have the user download VT outside of OMPI
and --disable-vt, or --enable-vt=/path/to/somewhere/else. If we
*replace* what is in the user's expanded tarball, they they cannot
revert to what came out of the tarball without re-expanding the
tarball (i.e., "make clean" and "make distclean" and whatnot do not
revert back to the real original state -- this is contrary to the
philosophy of those Automake targets).
--
Jeff Squyres
Cisco Systems
