Hi Steve, On 14.11.2011 14:13, Steve Kersley wrote: > As part of a revamp of some of my wpkg scripts, I want to move towards a model where I can use one package definition to install different versions of the application in order to test and/or perform staged installations of a new version by overriding the package version with one defined in the host or profile (as per http://wpkg.org/Variables#Applying_different_versions) > > Two hopefully simple questions came up that I've not found an answer to in the documentation: > > * Is there a way of reusing the same variable, redefining it between applications? i.e., if all scripts use PKG_VER. For instance, something like: > <profile id="custom"> > <variable name="PKG_VER" value="11.0.1" /> > <package package-id="flashplayer" /> > <variable name="PKG_VER" value="10.0.1.0" /> > <package package-id="acrobat" /> > </profile> > > Or does it parse the whole thing first and I would be better off rewriting the scripts to all use different internal variables: FLASHPLAYER_VER; JAVA_VER etc? (The latter will obviously require more work every time I import a script from the website) WPKG parses all veriables at once and evaluates them: - Host variables - Profile variables - Package variables In your example the PKG_VER variable for all packages will likely have the "10.0.1.0" value assigned. I think according to the XSD the profile variable definitions are supposed to be listed first and then the package references follow; but not mixed. Although WPKG itself supports mixing them; but as I wrote multiple definitions of the same variable within one scope will overwrite another variable with the same name. So if you want to define custom VER packages for different packages you need to have a variable defined for each of the packages. Just as you wrote: - FLASHPLAYER_VER - ACROBAT_VER ... To ease package adaptation in this special case it might be sufficient to insert <variable name="PKG_VER" value="%FLASHPLAYER_VER%" /> On top of the package copied from wpkg.org example. This way there is not much adaptation required. > * Is there any way of performing conditional actions/definitions dependant on the required package version - through extended host attribute matching for instance? The reason for this might be that the install method may be different from one version to the next, but if you're wanting to test deployment first don't want to rewrite the whole script and break it for machines still needing the older version. For instance, Acrobat Reader 1.0.1.1 needs a command line that installs 1.0.1.0 plus a patch to 1.0.1.1 rather than a single installer, so I can't just use a filename based on the final version number. Use conditional commands as supported by latest WPKG 1.2.1-RC. Conditions can be based on your environment variables too. br, Rainer |