[wpkg-users] Resuming actions after reboot

[Rainer Meier]

Hi Malte,

> That's what I do for the upgrade actions and it might indeed be an option for 
> install, too (ignoring the exit code).
> Yet it occurs to me that such a feature might be worth some more exploration?  
> Or to put it another way: I'm in the process of gradually switching our 
> software deployment to WPKG and should I encounter more cases where a reboot 
> in the middle of the installation is needed - and maybe less easily worked 
> around than with TightVNC - I might (very very very vague "might") give it a 
> try.  Thus the next question: if that happens, would this be something you'd 
> include when given a patch, or would this be rather unwanted?

With the current architecture and without introducing major changes I don't
think there is an easy way to save this state during the process yet.

In addition it's quite easy to achieve this "resume" by custom scripts. Moreover
I've come across a problem where I could not handle it with the current
implementation.

In more detail such a resume is slightly against the basic principle of WPKG.
WPKG just executes the commands in order and it is intended that a command can
(even in the middle of the process) issue a reboot. Some commands even do by
themselves because they do not have a switch to turn this off.
WPKG is designed in this case to use the checks to verify if the application is
installed. So to be more specific the checks allow WPKG to verify every detail
of an application installation. In your case WPKG can verify the file version of
WinVNC.exe, it can also verify every registry value associated to the "winsvc"
service and if one of the values is wrong, then it can start again running the
defined commands.
As a matter of fact all commands should be designed in a way that they can be
run as often as WPKG decides to without failing.

If all these rules are met, then there is no need for WPKG to resume at a
specific command - and even worse this would probably break some existing
packages. This includes a couple of my packages (as far as I remember) which are
making use of the fact that WPKG will start from the first command on next run
if one of them fails.


To explain a possibility to implement a resume functionality.

Simple use a CMD script to install your application. It might look as follows:

@echo off
set INSTALL_LOC=%~dp0
set STATUS_LOC=%TEMP\TightVNC
set INSTALL_DIR=%ProgramFiles%\TightVNC

mkdir "%STATUS_LOC%"

if exist "%STATUS_LOC%\install.done" goto skipinstall
start /wait "install" "%SOFTWARE%\tightvnc\tightvnc-1.3.10-setup.exe" /SP-
/VERYSILENT /NORESTART /RESTARTEXITCODE=3010
set EXIT_CODE=%ERRORLEVEL%
echo done > "%STATUS_LOC%\install.done"
if %EXIT_CODE% = 3010 exit /b 3010
:skipinstall

if exist "%STATUS_LOC%\firewall.done" goto skipfirewall
start /wait "firewall" netsh firewall add allowedprogram
program="%ProgramFiles%\TightVNC\WinVNC.exe" name="VNC" scope=ALL profile=ALL'
echo done > "%STATUS_LOC%\firewall.done"
:skipfirewall

...
echo done > "%INSTALL_DIR%\tightvnc1310.done"
exit /b 0

I admit I did not test it yet and it's not fully complete. However you get the
point I guess. Each step writes a persistent status to the disk. If the step has
been completed on last run then it will just skip it. If the step has not been
run (or failed du to unexpected termination) it will not write the file and
therefore the script will re-do this step on next trun.

The package definition of WPKG needs to be extended to check for existence of
"%INSTALL_DIR%\tightvnc1310.done" and then WPKG will know when the script
completed all its steps.

This extremely simple approach is one of the advantage of WPKG to be able to run
every script.


I did not yet deploy TightVNC and it looks that removing/stopping the service
before upgrade is a simple way to (possibly) solve the issue. Investing a lot of
effort into a feature which possibly breaks existing deployments and on the
other side can be easily worked around using some custom handling code (see
above) looks not very logical to me. I personally prefer to keep WPKG as simple
and small as possible and on the other side implement extension points to allow
handling of "strange" cases.
So for me it looks at the moment there is no single package known to me which
really requires this "resuming" possibility - so I personally don't think it's
worth the effort and potential problems. It would definitely void the simple
KISS approach I am trying to follow.

I just remember some "small" requests (eg. recently somebody filed a bug about
flushing STDOUT/STDERR. And at the end handling it properly required about 10
releases and a lot of work-arounds even if the original requester just changed
two lines of code. So introducing such wider changes definitely include a huge
potential for problems while potentially providing help for only a coupule out
of millions of software installers out there (while not one single installer is
known to me yet).

What do you think about?

br,
Rainer