[wpkg-users] [Bug 276] pre-download tag

[bugzilla-daemon at bugzilla.wpkg.org]

http://bugzilla.wpkg.org/show_bug.cgi?id=276

Rainer Meier <r.meier at wpkg.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |r.meier at wpkg.org
         Resolution|                            |WONTFIX

--- Comment #1 from Rainer Meier <r.meier at wpkg.org>  ---
Hi Rob,


I thought about this for a while and came to the conclusion that this request
insn't helpful to provide stable and reliable software deployment. I am going
to explain in a bit more detail.

First of all WPKG can't just look for such outstanding commands which need to
be run before. Implementing this would require to run these commands in
parallel thread (which is not supported in WSH) and moreover to keep track of
execution of each single command (which also might have dependencies between
each other). As a result your package install commands will anyway have to wait
for the completion of these commands before the package commands itself can run
and install the package.
Even worse such detached tasks would require detailed additional checks to
verify if they completed properly in background or if they have been
interrupted (process termination, timeouts, reboot, shutdown...).
So in any case the package won't be able to install before your pre-run
commands actually finished doing its task.

Moreover if you really want to decouple download from installing, then you can
actually do already using current WPKG implementation. Here's some suggestion
how you could do it:
First create a command which is handling the download. This command could run
detached download process. For example use:
<command type="install" cmd="\\path\to\download-script.cmd" />

Within the script use something like
@echo off
start "%dp0detached-download-job.cmd"


Note that "start" does not use the "/wait" argument, so it's running the job in
detached mode, not waiting for its termination.
And detached-download-job.cmd containing something like:
@echo off
if exist "%TEMP%\download-target\setup.exe" goto skipDownload
robocopy .....
echo complete > "%TEMP%\download-target\done"
:skipDownload


So "detached-download-job.cmd" will run in background without WPKG waiting for
it since download-script.cmd will terminate immediately.

Of course now the download is not finished when WPKG start the next command:
<command type="install" cmd="\\path\to\silentInstaller.cmd" />

While silentInstaller.cmd just contains some lines like:
@echo off
if exist "%TEMP%\download-target\complete" (
  echo Found downloaded installer
  start /wait "Installer" "%TEMP%\download-target\setup.exe" /silentSwitch
) else (
  echo Download not available, maybe not finished yet
  exit /b 1
)

So of course the WPKG will report the package as being failed to install on
first run since silentInstaller.cmd will return exit code 1 immediately. But
this is exactly what we want to achieve here. The package will have to wait for
the download to finish before it can install. And it's also correct in terms of
WPKG package database maintenance since the package won't be inserted to local
wpkg.xml until it's fully installed.
So the package will perhaps be applied next time WPKG is run. If the download
in previous run completed corretly it will make detached-download-job.cmd not
performing any action and the second command (silentInstaller.cmd) starting the
actual installation.

These 2 commands now entirely make sure the download is completely detached
from install. It just needs (at least) two WPKG runs to complete installation.
There is nothing wrong in allowing WPKG to fail on purpose while installing the
package.

You could also slightly modify the approach and start silent install in
detached process (right after robocopy completes in detached cmd script). This
would perhaps allow early-installation of the software. WPKG will still fail on
first run since obviously installation is not done yet. But on next run it will
succeed if your checks properly check for correctly installed software. In this
case you basically just need one single command:

<command type="install" cmd="\\path\to\download-script.cmd" />

Within the script use something like
@echo off
if exist "%ProgramFiles%\application\application.exe" goto skipInstall
start "%dp0detached-download-job.cmd"
:skipInstall

And detached-download-job.cmd containing something like
@echo off
if exist "%TEMP%\download-target\setup.exe" goto skipDownload
robocopy .....
:skipDownload
start /wait "install" "%TEMP%\download-target\setup.exe" /silentSwitch


In this script set WPKG will initiate detached wonload/install process on each
run. If it completes successfully, then on next WPKG run the command just
terminates (exit code 0) and WPKG then verifies (using its checks) that the
software is applied correctly. As a result on first run WPKG will report an
install error (which is exactly what we want since the application IS NOT
INSTALLED YET) and on second run perhaps complete.

Unfortunately in this second option you would never know when such an
install/upgrade takes place. So it might happen in the middle of some work.
Scheduled reboot or applications opened by the user might conflict with the
installer which just launches any time later.



Another alternative solution I've seen documented is to first synchronized the
complete WPKG tree to local drive (e.g c:\wpkg-repository) and run WPKG from
local drive. This requires pre-run task to synchornize the local repository and
also duplicates the complete software repository on clients. Of course this
requires quite some additional space on clients as well and in most cases isn't
an option but offers fully local installation.

-- 
Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.