[wpkg-users] Refresh local WKPG.XML
Kenny Bayless
kbayless at gmail.com
Tue May 17 21:41:29 CEST 2011
On Tue, May 17, 2011 at 2:12 PM, Rainer Meier <r.meier at wpkg.org> wrote:
> 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.
>
>
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.
> 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.
>
>
Excellent information, thanks!
> 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
>
--
Kenny Bayless
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wpkg.org/pipermail/wpkg-users/attachments/20110517/3037370e/attachment-0002.html>
More information about the wpkg-users
mailing list