Re: [open-vm-tools-devel] Gentoo integration

[Adar D. <ad...@vm...>]

> we're currently developing an open-vm-tools ebuild for=20
> inclusion into Gentoo=20
> Linux.
> The development progress can be tracked here:
> http://bugs.gentoo.org/show_bug.cgi?id=3D192377

Cool, thanks for letting us know. Did you find the packaging guidelines
useful? Was there anything that could have used clarification?

> Our current blockers are:
> - it doesn't build without X (missing libXrandr and probably=20
> libXtst too),=20
> although --disable-x and --without-multimon was given as argument=20
> to ./configure

As you said towards the end of your e-mail, adding a --disable-X =
configure
option sounds like a good idea, though I think you'll need to disable =
both
the toolbox and vmware-user (there may be some usable pieces of =
vmware-user
that could build without the X devel libraries; I'm not sure).=20

> - the xferlogs tool which is mentioned in the packaging guide=20
> isn't included=20
> in the sources - what happened to this tool?

I see it mentioned in the packaging guidelines, but it's not in the =
source.
I'll look into this...

> - the file 'guestlib.so' isn't built - couldn't figure out why yet..

Can you provide the build output? Is there some kind of error?

> We're also doing some additional patching, maybe some of this=20
> changes sound=20
> useful to the upstream developers for changing/including them.
> - disabling the toolbox when X is not used (I'd wish to do this using=20
> a ./configure argument like --disable-toolbox)
> - modification of the VmwareDnD path, as /tmp is rather=20
> stupid if the user=20
> uses scripts which clean up /tmp on startup or similar. We're using=20
> now /var/tmp/vmware/dnd. Would be nice as ./configure argument=20
> like --dnd-dir=3D/var/foobar.
> - Gentoo specific initscript for the vmware-guestd (dummy=20
> replacement coming=20
> soon...)

In general we'd like to accept patches, though we still don't have the
infrastructure for it. We're working on putting together the =
contribution
agreement, and we still need to get source control up and running. Stay =
tuned
for updates on that.

For now, make whatever changes you need on your end, and when we can =
take
patches, you'll be able to remove yours.

BTW, the reason VMwareDnD lives in /tmp is because it serves as the =
staging
directory for files that have been dropped into the guest. These files =
should
be wiped at startup time, otherwise they'll accumulate and fill up the =
disk.
Unfortunately, the DnD protocol doesn't specify any kind of lifespan for
dropped files, so we must keep them around until no application could
possibly use them anymore (such as at reboot time).