Hi both,
On 17.05.2011 20:23, John Danks wrote:
> It looks like you can have as many arbitrarily named variables as you like.
This is correct. WPKG Client can define as many variables as you like. The
server (wpkg.js) will just be fine using them in package definition.
About your "fixup" of existing clients:
If you just use UNC paths for installers you're absolutely fine. Just fix your
UNC paths in server-side XML files. Existing clients will not care about it as
the packages are already installed and clients which upgrade or install (new
clients) will use the updates XML definition on the server - which is supposed
to be correct then.
The main issue which could arise is if you used absolute UNC paths in uninstall
entries. These entries are stored in local WPKG database
(%SystemRoot%\system32\wpkg.xml) and used when a package is removed from the
profile.
If your packages just use local commands/paths in uninstall entries then you
don't have to do anything. Just leave the packages with wrong install paths in
local package database (WPKG will not use them).
In case your clients now have invalid UNC paths in local packages (e.g. "msiexec
/qn /x \\removed-server\share\software\package.msi" then you might simply do the
following:
- Update your server-side package:
- increase revision
- make sure your upgrade commands either perform no action or at least work
even if exactly this version is already installed.
Now you can simply remove the package from the server-side profile.
Why is this going to work?
Well, if you did not disable it there is a feature in WPKG I call
"upgrade-before-remove". In this case WPKG would detect that there is a local
package to be removed. But before removing it WPKG will upgrade to the latest
package as defined on server side to assure the uninstall process runs smooth
(latest tested uninstall procedure).
So if you don't want to uninstall, then just continue and fix up the package
paths on server side. In case you need to uninstall a package either let WPKG
rely on the locally-stored uninstall entries in local packages or just provide
an updated package on server side so WPKG will upgrade before removing the
package.
This way you can always easily update broken packages on client side.
btw. For MSI packages (and most other installers) the upgrade command is
identical to the install command. Most installers detect if the same version is
already installed and therefore just exit with "success" exit code without
performing any action.
br,
Rainer
-------------------------------------------------------------------------
wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/
_______________________________________________
wpkg-users mailing list
wpkg-users@lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users
