<br><br><div class="gmail_quote">On Tue, May 17, 2011 at 2:12 PM, Rainer Meier <span dir="ltr"><<a href="mailto:r.meier@wpkg.org">r.meier@wpkg.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

Hi both,<br>
<div class="im"><br>
On 17.05.2011 20:23, John Danks wrote:<br>
> It looks like you can have as many arbitrarily named variables as you like.<br>
<br>
</div>This is correct. WPKG Client can define as many variables as you like. The<br>
server (wpkg.js) will just be fine using them in package definition.<br>
<br>
About your "fixup" of existing clients:<br>
If you just use UNC paths for installers you're absolutely fine. Just fix your<br>
UNC paths in server-side XML files. Existing clients will not care about it as<br>
the packages are already installed and clients which upgrade or install (new<br>
clients) will use the updates XML definition on the server - which is supposed<br>
to be correct then.<br>
<br>
The main issue which could arise is if you used absolute UNC paths in uninstall<br>
entries. These entries are stored in local WPKG database<br>
(%SystemRoot%\system32\wpkg.xml) and used when a package is removed from the<br>
profile.<br>
If your packages just use local commands/paths in uninstall entries then you<br>
don't have to do anything. Just leave the packages with wrong install paths in<br>
local package database (WPKG will not use them).<br>
In case your clients now have invalid UNC paths in local packages (e.g. "msiexec<br>
/qn /x \\removed-server\share\software\package.msi" then you might simply do the<br>
following:<br>
<br>
- Update your server-side package:<br>
  - increase revision<br>
  - make sure your upgrade commands either perform no action or at least work<br>
    even if exactly this version is already installed.<br>
<br></blockquote><div><br>I do have some packages that have uninstall commands that call to the outdated server, but I was planning to do exactly what you mention here - correct the commands, and increase the revision.  I have also implemented the variables (way overdo!), so this should not be a problem next time.<br>

 </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Now you can simply remove the package from the server-side profile.<br>
Why is this going to work?<br>
Well, if you did not disable it there is a feature in WPKG I call<br>
"upgrade-before-remove". In this case WPKG would detect that there is a local<br>
package to be removed. But before removing it WPKG will upgrade to the latest<br>
package as defined on server side to assure the uninstall process runs smooth<br>
(latest tested uninstall procedure).<br>
<br>
So if you don't want to uninstall, then just continue and fix up the package<br>
paths on server side. In case you need to uninstall a package either let WPKG<br>
rely on the locally-stored uninstall entries in local packages or just provide<br>
an updated package on server side so WPKG will upgrade before removing the package.<br>
<br>
This way you can always easily update broken packages on client side.<br>
<br></blockquote><div><br>Excellent information, thanks!<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
btw. For MSI packages (and most other installers) the upgrade command is<br>
identical to the install command. Most installers detect if the same version is<br>
already installed and therefore just exit with "success" exit code without<br>
performing any action.<br>
<br>
<br>
br,<br>
<font color="#888888">Rainer<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Kenny Bayless<br>