<html>
    <head>
      <base href="http://bugzilla.wpkg.org/" />
    </head>
    <body><span class="vcard"><a class="email" href="mailto:r.meier@wpkg.org" title="Rainer Meier <r.meier@wpkg.org>"> <span class="fn">Rainer Meier</span></a>
</span> changed
              <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - Intermittent problem Uninstall not found in System Context"
   href="http://bugzilla.wpkg.org/show_bug.cgi?id=287">bug 287</a>
          <br>
             <table border="1" cellspacing="0" cellpadding="8">
          <tr>
            <th>What</th>
            <th>Removed</th>
            <th>Added</th>
          </tr>

         <tr>
           <td style="text-align:right;">CC</td>
           <td>
                
           </td>
           <td>r.meier@wpkg.org
           </td>
         </tr></table>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - Intermittent problem Uninstall not found in System Context"
   href="http://bugzilla.wpkg.org/show_bug.cgi?id=287#c2">Comment # 2</a>
              on <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - Intermittent problem Uninstall not found in System Context"
   href="http://bugzilla.wpkg.org/show_bug.cgi?id=287">bug 287</a>
              from <span class="vcard"><a class="email" href="mailto:r.meier@wpkg.org" title="Rainer Meier <r.meier@wpkg.org>"> <span class="fn">Rainer Meier</span></a>
</span></b>
        <pre>Well, this often happens for custom installers which fork their own
installation process and the initial process terminates. You can usually run
such installers from command-line with silent options and you will be returned
to the prompt before the actual installation is finished.

Of course for WPKG it will run the uninstall checks right after the process it
launched terminated. In case of installers which fork installation processes
the uninstall entry might be written with some delay.

This is not a bug in WPKG but rather an issue (known) with broken silent
installers. The same even more frequently applies to uninstallers.


There are several ways to deal with such broken installers:
You might simply write a small wrapper script (e.g. a cmd shell script) which
launches the installer and waits for it to complete. Either by using a
hard-coded timeout (not recommended as installation time might vary a lot
depending on various circumstances) or by repeatedly checking for the installer
to finish its work. This check might be a check for a file created by the
installer or even the uninstall entry itself to appear. The key is that this
wrapper script should not terminate except in timeout case or if the installer
completed its job.

There is no general recipe working for any installer out there, it depends on
the specific program how such a wait function could look like.

For the time being try a shell script as follows:

@echo off
start /wait path\to\installer.exe /silent-options [...]
ping -n 600 localhost > NUL
exit 0

This will wait 10 minutes after launchning the installer. You might extend this
by a loop and file/registry checks rather than hard-coded wait time.</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are the QA Contact for the bug.</li>
      </ul>
    </body>
</html>