[wpkg-users] Resuming actions after reboot

[Malte Starostik]

Hi Rainer,

{sorry for the late reply}
Am Montag, 25. Mai 2009 20:25:27 schrieb Rainer Meier:
> > 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.

Fair enough.
[...]

> 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.

[...]

> 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

[...]

> :skipinstall
>
> if exist "%STATUS_LOC%\firewall.done" goto skipfirewall

[...]

> :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.

Thanks for pointing me into this direction.  Might use it should I encounter 
some package that's not as easily made non-rebooting with a service stop or 
similar.

[...]

> 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?

Thanks for taking the time to share your rationale for why some features might 
appear to be missing from WPKG but actually don't.
On second thought I absolutely have to agree.  Note to self: WPKG is more like 
a UNIXish command that performs professionally in its well-defined domain, 
waiting to be combined with other tools as they're fit.  <sarcasm>As opposed 
to the dreaded PHP way of providing zillions of almost but not quite similar 
bells and whistles for every kind of belling and whistling one might possibly 
need - except for when one needs a siren instead.</sarcasm>
Referring to a specialist external entity is usually a Good Thing indeed.

Regards,
Malte