>>> On 2/13/2009 at 2:00 AM, Dmitry Torokhov <d...@vmware.com> wrote: > What I don't like about this solution is that it adds yet another piece that > > needs to know where vmblock is mounted and when we move to FUSE-based > implementation the mount point is going to change.
granted, that is not a nice place... that's why I would have preferred this logic in the vmware-user-suid-wrapper itself. After all THAT is the program that takes care of it. > > Also, you still need to find a way to get vmware-user release/reacquire > vmblock when you update open-vm-tools package unless you want to force user > to > How do YOU do that? Sort of a post-install script scanning all PIDs to find any running vmware-user tasks and send them a SIGUSR2? Dbus signaling might be a neater solution for such things. > restart their desktop. I wonder if we need to adjust the packaging > guidelines > with regard to vmware-user/vmware-user-suid-wrapper... Guidelines are a good thing, but the proper functioning of an application should not solely base on the way it's packaged. Especially not if 'make install' hardly does anything of what is supposed to happen. Also think about users downloading the tarball and ./configure; make; sudo make install it. They will never know about all the fallouts they have to go through, as 'packaging guideline' does not sound very interesting for them. Dominique ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ open-vm-tools-devel mailing list open-vm-tools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open-vm-tools-devel
