[wpkg-users] Installs with /debug but not with client or standard /synchronize

[Rainer Meier]

Hi Michael,

On 08.01.2012 05:18, Michael MacKay wrote:
> I have several packages being processed at once, 5 upgrade installs, and 3
> software removals (setup as installs {msiexe /x} as they weren't installed with
> WPKG). The installs work (although they seem to continue after the client
> progress bar goes away, sometimes running after logging in) but the removals
> don't.  If I run cscript \\server\wpkg\wpkg.js /synchronize they don't remove
> but when I add /debug it removes them.  Any idea why it would work in debug mode
> but not with the client or normal /sync?

I have just set up a very simple test-case for this where I have installed 8 
packages, then upgraded 5 of them and removed 3 of them before next /synchronize 
run.
The result is the same no matter if I use the /debug flag or not. At least WPKG 
1.3.0 executes the same commands in both cases.

You say in your case WPKG seems to behave differently depending on whether the 
/debug flag is used or not. In terms of functionality it's supposed to work 
exactly the same way in both cases, just the amount of screen/log output is 
different. However this means that it could have an impact on execution time. 
And this is what my concern is about. Maybe you're running into strange timing 
problem with your commands defined while your commands execute fine in case 
small delays between execution of commands occurs.

However this would not be a WPKG issue but rather an issue in the called 
commands to be resolved.

If you want people on the list to help you might be able to provide a debug log 
(yes, you can still log debug-level log entries even if /debug is not used, see 
config.xml documentation on logLevel) for both runs, with /debug switch and 
without. So you or someone else can see whether something is going wrong in WPKG 
command execution.

If WPKG executes all desired upgrade and remove commands correctly, then it's 
usually an issue which has to be solved by fixing up the packages.
As you indicate that sometimes some commands seem to continue "after the client 
progress bar goes away" (I guess you're referring to logon delay of WPKG-client 
on Windows XP) this indicates that some of your commands might fork and continue 
to run in background while returning to WPKG too quickly. So you might have to 
add additional waits (e.g. insert commands like 'ping -n 10 localhost") or do 
more intelligent checking to wait for the command to complete before letting 
WPKG continue.

The VLC uninstaller is a very good example of bad practice, here I need to use 
such a similar loop to wait for the uninstaller to complete its job:

@echo off
:: This is required to evaluate the target of %ProgramFiles% on 64-bit systems
:: Please note that this is required only if you uninstall a 32-bit application.
set PROGRAM_FILES=%ProgramFiles%
if not "%ProgramFiles(x86)%" == "" set PROGRAM_FILES=%ProgramFiles(x86)%

::Application install folder
set APP_DIR=%PROGRAM_FILES%\VideoLAN\VLC

:: Path to the uninstaller (see path definition above)
set UNINSTALLER=%APP_DIR%\uninstall.exe

:: Options to be passed to the uninstaller in order to uninstall silently
set OPTIONS=/S

if not exist "%UNINSTALLER%" goto good_end
start /wait "Uninstall" "%UNINSTALLER%" %OPTIONS%
start "Uninstall" "%UNINSTALLER%" %OPTIONS%
REM Unfortunately the uninstaller seems to fork a child process and the parent
REM process exits immediately. So give it some time to uninstall
for /L %%C IN (1,1,30) DO (
   if not exist "%UNINSTALLER%" goto good_end
   ping -n 2 127.0.0.1 > NUL
)
:bad_end
exit /B 1

:good_end
if exist "%APP_DIR%" rmdir /s /q "%APP_DIR%"
exit /B 0



br,
Rainer