VMD-L Mailing List

From: Bogdan Costescu (Bogdan.Costescu_at_IWR.Uni-Heidelberg.De)
Date: Fri Feb 10 2006 - 12:05:03 CST

On Thu, 9 Feb 2006, John Stone wrote:

> One thing that's kept me away from doing much with VMWare and
> similar systems is that there's no support for OpenGL, so the best
> tests I'd likely be able to do would be running scripts and checking
> for correct functioning of the core VMD code.

I think that's already a lot, certainly much better than just hoping
that it works. For the OpenGL part, I don't think that it would make
that much sense anyway, because there you want to look at the output
which is often dependent not only on software but on hardware as well
and hardware like the last generations of nVIDIA/ATI/whatever graphics
chip can't be reasonably expected to be offered as virtualization...
Things might be different with the Xen approach, but I'll believe it
when I'll see it :-)

> Not all linux distros work within these hypervisor VM setups from
> what I've heard, so that might also be an interesting challenge all
> on its own.

Maybe you're hoping for too much ;-) Although it would be nice, you
probably can't guarantee that VMD functions perfectly in _all_ Linux
distros. But if you are able to cover the big majority of the users
with only a small effort (say, by checking all or most of the "major"
distros), then the rest could probably be handled on a case-by-case
basis.

> If anyone has such a VMWare or xen setup running with 5 or 6 client
> Linux distros, I'd be curious to hear your experiences.

VMWare offers premade VMs with some Linux distributions:

http://www.vmware.com/vmtn/vm/

[ Another disclaimer: I have no affiliation to VMWare. I'm just a
user. ]

> Regarding source RPMs. One of the problems I'd have in doing something
> that automated is that I've had to manually patch various bugs in FLTK,
> Tcl, Tk, Python, etc so that they build correctly on some of the target
> platforms.

Indeed, this is a problem. The standard answer that would come from
the Fedora community for example would be to mention these bugs
upstream (in this examples, to the developers of FLTK, Tcl, etc.) so
that the next release from them would include the fix; this release
could be made a prerequisite for building/installing. Not mentioning
it upstream greatly reduces the chances of ever seeing it fixed and
creates a burden for long term maintenance. For the slower moving
enterprise distros, it helps to both have an upstream fix and file a
bug in the distro's bug database; the distro makers are usually quite
sensitive to ISV reports (you being an ISV in this respect) and there
is a reasonably good chance of having a fix in the next update,
service pack or whatever it is called.

When all else fails, there is still the possibility of just providing
RPMs to be installed alongside the distro's normal (and buggy)
version. Replacing the distro's packages is usually a bad idea, as was
shown in the Fedora world for example by some of the ATRPMS packages.

> Is there a nice way to have a patch get applied to a required SRPM
> before it gets installed?

Yes. A normal SRPM contains one or more sources (usually as tar.gz or
tar.bz2) and zero to many patches. In the first stage of the rpmbuild
process ('rpmbuild -bp'), the sources are unpacked and all the patches
are applied. Patches are usually in the 'diff -u' format, but anything
that 'patch' accepts is probably fine.There are also ways to apply
patches or configure the build process based on defines (from the
'rpmbuild' command line) or environment data.

I don't know how many people on this list are interested in these
details, so maybe this discussion should be made private. I certainly
would be willing to help creating a RPM (or set of RPMs) for VMD. 

-- 
Bogdan Costescu
IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen
Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY
Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868
E-mail: Bogdan.Costescu_at_IWR.Uni-Heidelberg.De