[wpkg-users] package upgrade scenario
Robin Roevens
robin.roevens at cocks.be
Wed Aug 19 09:08:41 CEST 2009
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:
> From:
>
> Lukasz Zalewski <lukas at dcs.qmul.ac.uk>
>
> To:
>
> wpkg-users at lists.wpkg.org
>
> Date:
>
> 19.08.2009 00:18
>
> Subject:
>
> [wpkg-users] package upgrade scenario
>
> Sent by:
>
> wpkg-users-bounces at lists.wpkg.org
>
> Hi all,
> I'm sure this topic has been mentioned few times in the past (i have
> found a previous thread entitled Basic Question), but it is still
> unclear to me how the update process should commence. So as an example i
> have a firefox package defined as follows:
> package
> id="firefox3501"
> 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 i want to update it to version 3.5.02 so do i define a new package?
e.g.
> <package
> id="firefox3502"
> 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>
>
> I suspect this is not the way to go as id=firefox3502 is separate
> package rather than the upgrade and the "update" happens only due to the
> nature of firefox installer. Am I right? If so how does one structure
> the update? From what i read from the previous posts one bumps up the
> revision number and changes install (and possibly upgrade) cmd. What
> about uninstall cmd? does this refer to the previous installation (I
> guess firefox is a bad example as uninstall paths in default
> configuration will be the same)? What if there has been few updates?
> Which uninstall cmd should be used? Is it sequential process when one
> revision has to follow another one in the sequence (i mean wpkg sequence
> rather than prduct release sequence)? So would this be correct for
> firefox update based on the original entry
> package
> id="firefox3501"
> 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.1.exe" /S /noreboot' />
> <upgrade cmd='"%SOFTWARE%\firefox\firefox3.5.02\Firefox Setup
> 3.5.1.exe" /S /noreboot' />
> <remove cmd='"%PROGRAMFILES%\Mozilla Firefox\uninstall\helper.exe"
> /S' />
> </package>
>
> Again if this is the case how does one keep update trail if the package
> configuration is updated constantly underneath itself?
>
> Regards
>
> Luk
>
-------------------------------------------------------------------------
> wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/
> wpkg-users/
> _______________________________________________
> wpkg-users mailing list
> wpkg-users at lists.wpkg.org
> http://lists.wpkg.org/mailman/listinfo/wpkg-users
--
Denk aan het milieu - is het nodig deze mail te printen?
** Email Disclaimer:
** This e-mail and the information it contains may be confidential, legally privileged and protected by law. Access by the intended recipient only is authorised. If you are not the intended recipient, please notify the sender immediately and delete this e-mail from your system. Any review, distribution, reproduction, publication or other use of this e-mail by persons or entities other than the intended recipient is prohibited.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wpkg.org/pipermail/wpkg-users/attachments/20090819/c07fecf7/attachment-0002.html>
More information about the wpkg-users
mailing list