[wpkg-users] package upgrade scenario

[Lukasz Zalewski]

Robin Roevens wrote:
> Hi Lukasz
> 
> A package update is indeed done by _not_changing the id (or creating 
> another package with diferent id) but by changing the revision. And the 
> install and upgrade command's if needed.
> In the firefox case this would be
> <package
>    id="firefox"
>    name="Mozilla Firefox"
>    revision="3501"
>    reboot="false"
>    priority="10">
>    <check type="uninstall" condition="exists" path="Mozilla Firefox 
> (3.5.1)" />
>    <install cmd='"%SOFTWARE%\firefox\firefox3.5.01\Firefox Setup 
> 3.5.1.exe" /S /noreboot' />
>    <upgrade cmd='"%SOFTWARE%\firefox\firefox3.5.01\Firefox Setup 
> 3.5.1.exe" /S /noreboot' />
>    <remove cmd='"%PROGRAMFILES%\Mozilla Firefox\uninstall\helper.exe" /S' />
> </package>
> 
> and to make firefox update to version 3.5.2 you change this package into:
> <package
>    id="firefox"
>    name="Mozilla Firefox"
>    revision="3502"
>    reboot="false"
>    priority="10">
>    <check type="uninstall" condition="exists" path="Mozilla Firefox 
> (3.5.2)" />
>    <install cmd='"%SOFTWARE%\firefox\firefox3.5.02\Firefox Setup 
> 3.5.2.exe" /S /noreboot' />
>    <upgrade cmd='"%SOFTWARE%\firefox\firefox3.5.02\Firefox Setup 
> 3.5.2.exe" /S /noreboot' />
>    <remove cmd='"%PROGRAMFILES%\Mozilla Firefox\uninstall\helper.exe" /S' />
> </package>
> 
> By doing so WPKG notices the new revision of the already installed 
> package on a client and starts the upgrade actions.
> After the update, WPKG saves/replaces this package-node in it's own 
> local wpkg.xml file so it knows which revision is installed, and how to 
> uninstall it when needed.
> When this package is later removed from the profile, WPKG will uninstall 
> this package using the saved package information in it's local wpkg.xml 
> file.
> In other words, the uninstall action always has to contain the 
> instructions of how to uninstall the current revision, not the previous 
> one as WPKG 'remembers' the uninstall command of the previous revision
> 
> But because WPKG saves the full package node to it's local wpkg.xml 
> file, you should always increment the package revision when anything 
> changes in the package definition, even when correcting a simple typo.. 
> Because otherwise the change will never go into the local wpkg.xml file 
> on the clients that already have the current revision of the package. 
> And thus there is a chance that the uninstall command (if the typo where 
> there) of the local package-node copy is not correct.
> But since WPKG doesn't know what has changed in the package, it performs 
> a full update when a revision is found so you must make sure your update 
> commands can be executed always, even if there is nothing to update. But 
> my expierience is that most installers do a clean exit when they find 
> the software is already up-to-date..
> If you have software where the installer fails when trying to update an 
> up-to-date version, you could create a batch-file which checks for the 
> software first and then conditionally executes the update. Then call 
> this batchfile from the upgrade action in the package node.
> 
> Personally I don't use the actual software version in my package 
> revisions. But I use the date of the last change on the package in the 
> format YYYYMMDDX where X is an integer that counts the amount of changes 
> in one day. Meaning that if I create an update for a package today, the 
> package gets revision 200908190. If a few hours later I see I made a 
> typo or any other error in the package, then I change it and the 
> revision is then set to 200908191.
> 
> When, for some reason, a client missed a few package revisions, they 
> won't be installed/updated sequentially as WPKG doesn't know of the 
> existance of any previous revisions besides the one that is currently 
> installed and the latest one on the server. So you must also make sure 
> any update command works with any previous revision that could be on a 
> client. (also again, most installer program's can handle this without a 
> problem.. Another example of how you could do this is the Java package: 
> http://wpkg.org/Java where any old version is first uninstalled before 
> installing a new version)
> 
> About keeping trail of the updates, I personally use SubVersion (SVN) 
> for this. The complete WPKG tree is put in SVN, so I can keep track of 
> any changes made and eventually revert back to older package versions..
> 
> Hope this answers all your questions?
> 
> Best Regards
> 
> Robin Roevens
> 
> wpkg-users-bounces at lists.wpkg.org wrote on 19.08.2009 00:17:45:
> 

Thanks a lot Robin, that has indeed cleared up some of the confusion :)

I have a follow-up question though, I'm in the process of integrating 
wpkg with our existing machines which have already software installed on 
them, so created packages would be applied to all of even to the ones 
that do not have the previous software installed, unless the installed 
version is the same as in the package.xml.
So Am i right thinking that i have to use multiple check conditions that 
besides checking for the current release can check for the previous ones 
  or for a particular registry/file existance. Would this ensure that 
only updates are applied to those that need them rather than mass 
installation of everything

Cheers

Luk