Hi Heiko, On 05.04.2012 08:17, heiko.helmle at horiba.com wrote: > Does WPKG handle multiple versions of the same package of is this planned. It's > a corner case - for example Vmware Infrastructure Client installs different > versions all having the same DisplayName. So if you manage 4.1 and 5.0 servers > you have two Clients installed with different version fields. WPKG currently does not handle multiple revisions of the same WPKG package in the same package database as of internal data structure. It's a feature planned, but it requires soma rather large re-structuring and in almost all cases it's better not even to think about using the same package in multiple revisions in one environment. As a work-around you might also just define multiple packages with different IDs. Since the packages seem to be independent (both can be installed in parallel) this might be a valid option. For example create packages like "vmware-infrastructure-client-5" and "vmware-infrastructure-client-4" and handle them independently. > But if i <check type='uninstall' condition='versiongreaterorequal' path='VMware > Infrastructure Client' value='5.0'/> If both uninstall entries have the same display name. Then WPKG of course compares the version on firs occurrence. However you might jusr replace the uninstall check by a registry check and point it to the concrete uninstall entry (as the uninstall entries will have different locations then). > then wpkg always picks up the 4.1 one and will try to install the 5.0, though > both are already installed. Therefore using registry checks allows you to point WPKG to concrete uninstall entries if the uninstall name is not unique. Alternatively the code of WPKG would have to be changed to look for more uninstall entries after a matching one has been found. Unfortunately this would have a negative impact on the overall performance. Every uninstall entry search will have to look for ALL uninstall entries rather than stop the search on the first matching one found. Moreover it would still have a negative impact if you're going to look for "versiongreaterorequal" which will also match version 5.0 on installation of version 4.1. Therefore you still would have to define a registry or file version check in order to verify that version 4.1 is installed properly (as uninstall matching for greater-or-equal on 4.1 would also match for version 5.0). So the recommendation here is to either use registry or file checks to verify the installation rather than relying on uninstall checks. > If you have packages with slightly different names you can get around that by > writing more exact checks, but if the names are identical I have yet to find a > workaround... - File based checks - Registry checks br, Rainer |