|
From: Justin M. F. <jmf...@li...> - 2007-11-01 19:11:54
|
On Thu, 2007-11-01 at 10:16 -0500, Justin M. Forbes wrote: > On Thu, 2007-11-01 at 11:05 -0400, Sean Dilda wrote: > > Justin M. Forbes wrote: > > > > > Aha, after a bit of probing, it seems that it chokes > > > when /etc/vmware-tools/poweroff-vm-default is not present instead of > > > simply falling back to CONFVAL_HALT_DEFAULT, though I am not sure why it > > > works on the second try. I guess the question is, should we include > > > default scripts, or just make the code DTRT if the scripts are not > > > present. > > > > > > > The right answer is probably to do both. Include the scripts, and make > > sure the code DTRT if they're not there. > > > In that case, the default scripts would really just do the default > fallback. In other words, the behavior would be the same if the scripts > were present or not. In this case, it would be better to not package > the scripts, so that users could replace them without worrying about > getting trampled by their package manager, or more importantly, the > packaged implementation could be used while packages providing more > specific scripts could be packaged elsewhere without file conflicts. > Okay, a bit more reading and understanding the code here... I didn't realize those are pre/post scripts. So the issue is that VMware Workstation or VMware Server shouldn't complain if guestd replies not implemented on those scripts, but no point in changing the client to give a fake response either. It seems most sane to actually add/package those scripts and make them check some given dir (say /etc/vmware-tools/scripts.d) for the corresponding script and execute the script if it exists, exit cleanly if not. that not only keeps the console from erroring or complaining about missing functionality, but allows people to package proper shutdown and startup scripts if they have any real needs. Sorry for the earlier confusion. Justin |