On Tue, May 17, 2011 at 2:12 PM, Rainer Meier <r.me...@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
------------------------------------------------------------------------- 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
