[wpkg-users] WPKG handling multiple packages

[Rainer Meier]

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