<font size=2 face="sans-serif">Hi Lukasz</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br><font size=2 face="sans-serif">In the firefox case this would be</font>
<br><tt><font size=2><package<br>
    id="firefox"<br>
    name="Mozilla Firefox"<br>
    revision="3501"<br>
    reboot="false"<br>
    priority="10"><br>
    <check type="uninstall" condition="exists"
path="Mozilla Firefox (3.5.1)" /><br>
    <install cmd='"%SOFTWARE%\firefox\firefox3.5.01\Firefox
Setup 3.5.1.exe" /S /noreboot' /><br>
    <upgrade cmd='"%SOFTWARE%\firefox\firefox3.5.01\Firefox
Setup 3.5.1.exe" /S /noreboot' /><br>
    <remove cmd='"%PROGRAMFILES%\Mozilla Firefox\uninstall\helper.exe"
/S' /><br>
</package></font></tt>
<br>
<br><font size=2 face="sans-serif">and to make firefox update to version
3.5.2 you change this package into:</font>
<br><tt><font size=2><package<br>
    id="firefox"<br>
    name="Mozilla Firefox"<br>
    revision="3502"<br>
    reboot="false"<br>
    priority="10"><br>
    <check type="uninstall" condition="exists"
path="Mozilla Firefox (3.5.2)" /><br>
    <install cmd='"%SOFTWARE%\firefox\firefox3.5.02\Firefox
Setup 3.5.2.exe" /S /noreboot' /><br>
    <upgrade cmd='"%SOFTWARE%\firefox\firefox3.5.02\Firefox
Setup 3.5.2.exe" /S /noreboot' /><br>
    <remove cmd='"%PROGRAMFILES%\Mozilla Firefox\uninstall\helper.exe"
/S' /><br>
</package></font></tt>
<br>
<br><font size=2 face="sans-serif">By doing so WPKG notices the new revision
of the already installed package on a client and starts the upgrade actions.</font>
<br><font size=2 face="sans-serif">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.</font>
<br><font size=2 face="sans-serif">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.</font>
<br><font size=2 face="sans-serif">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</font>
<br>
<br><font size=2 face="sans-serif">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. </font>
<br><font size=2 face="sans-serif">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..</font>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">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: </font><a href=http://wpkg.org/Java><font size=2 face="sans-serif">http://wpkg.org/Java</font></a><font size=2 face="sans-serif">
where any old version is first uninstalled before installing a new version)</font>
<br>
<br><font size=2 face="sans-serif">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..</font>
<br>
<br><font size=2 face="sans-serif">Hope this answers all your questions?</font>
<br>
<br><font size=2 face="sans-serif">Best Regards</font>
<br>
<br><font size=2 face="sans-serif">Robin Roevens</font>
<br>
<br><tt><font size=2>wpkg-users-bounces@lists.wpkg.org wrote on 19.08.2009
00:17:45:<br>
<br>
> From:</font></tt>
<br><tt><font size=2>> <br>
> Lukasz Zalewski <lukas@dcs.qmul.ac.uk></font></tt>
<br><tt><font size=2>> <br>
> To:</font></tt>
<br><tt><font size=2>> <br>
> wpkg-users@lists.wpkg.org</font></tt>
<br><tt><font size=2>> <br>
> Date:</font></tt>
<br><tt><font size=2>> <br>
> 19.08.2009 00:18</font></tt>
<br><tt><font size=2>> <br>
> Subject:</font></tt>
<br><tt><font size=2>> <br>
> [wpkg-users] package upgrade scenario</font></tt>
<br><tt><font size=2>> <br>
> Sent by:</font></tt>
<br><tt><font size=2>> <br>
> wpkg-users-bounces@lists.wpkg.org</font></tt>
<br><tt><font size=2>> <br>
> Hi all,<br>
> I'm sure this topic has been mentioned few times in the past (i have
<br>
> found a previous thread entitled Basic Question), but it is still
<br>
> unclear to me how the update process should commence. So as an example
i <br>
> have a firefox package defined as follows:<br>
> package<br>
>     id="firefox3501"<br>
>     name="Mozilla Firefox"<br>
>     revision="3501"<br>
>     reboot="false"<br>
>     priority="10"><br>
>     <check type="uninstall" condition="exists"
path="Mozilla Firefox <br>
> (3.5.1)" /><br>
>     <install cmd='"%SOFTWARE%\firefox\firefox3.5.01\Firefox
Setup <br>
> 3.5.1.exe" /S /noreboot' /><br>
>     <upgrade cmd='"%SOFTWARE%\firefox\firefox3.5.01\Firefox
Setup <br>
> 3.5.1.exe" /S /noreboot' /><br>
>     <remove cmd='"%PROGRAMFILES%\Mozilla Firefox\uninstall\helper.exe"
<br>
> /S' /><br>
> </package><br>
> <br>
> and i want to update it to version 3.5.02 so do i define a new package?
e.g.<br>
> <package<br>
>     id="firefox3502"<br>
>     name="Mozilla Firefox"<br>
>     revision="3502"<br>
>     reboot="false"<br>
>     priority="10"><br>
>     <check type="uninstall" condition="exists"
path="Mozilla Firefox <br>
> (3.5.2)" /><br>
>     <install cmd='"%SOFTWARE%\firefox\firefox3.5.02\Firefox
Setup <br>
> 3.5.2.exe" /S /noreboot' /><br>
>     <upgrade cmd='"%SOFTWARE%\firefox\firefox3.5.02\Firefox
Setup <br>
> 3.5.2.exe" /S /noreboot' /><br>
>     <remove cmd='"%PROGRAMFILES%\Mozilla Firefox\uninstall\helper.exe"
<br>
> /S' /><br>
> </package><br>
> <br>
> I suspect this is not the way to go as id=firefox3502 is separate
<br>
> package rather than the upgrade and the "update" happens
only due to the <br>
> nature of firefox installer. Am I right? If so how does one structure
<br>
> the update? From what i read from the previous posts one bumps up
the <br>
> revision number and changes install (and possibly upgrade) cmd. What
<br>
> about uninstall cmd? does this refer to the previous installation
(I <br>
> guess firefox is a bad example as uninstall paths in default <br>
> configuration will be the same)? What if there has been few updates?
<br>
> Which uninstall cmd should be used? Is it sequential process when
one <br>
> revision has to follow another one in the sequence (i mean wpkg sequence
<br>
> rather than prduct release sequence)? So would this be correct for
<br>
> firefox update based on the original entry<br>
> package<br>
>     id="firefox3501"<br>
>     name="Mozilla Firefox"<br>
>     revision="3502"<br>
>     reboot="false"<br>
>     priority="10"><br>
>     <check type="uninstall" condition="exists"
path="Mozilla Firefox <br>
> (3.5.2)" /><br>
>     <install cmd='"%SOFTWARE%\firefox\firefox3.5.02\Firefox
Setup <br>
> 3.5.1.exe" /S /noreboot' /><br>
>     <upgrade cmd='"%SOFTWARE%\firefox\firefox3.5.02\Firefox
Setup <br>
> 3.5.1.exe" /S /noreboot' /><br>
>     <remove cmd='"%PROGRAMFILES%\Mozilla Firefox\uninstall\helper.exe"
<br>
> /S' /><br>
> </package><br>
> <br>
> Again if this is the case how does one keep update trail if the package
<br>
> configuration is updated constantly underneath itself?<br>
> <br>
> Regards<br>
> <br>
> Luk<br>
> -------------------------------------------------------------------------<br>
> wpkg-users mailing list archives >> </font></tt><a href=http://lists.wpkg.org/pipermail/><tt><font size=2>http://lists.wpkg.org/pipermail/</font></tt></a><tt><font size=2><br>
> wpkg-users/<br>
> _______________________________________________<br>
> wpkg-users mailing list<br>
> wpkg-users@lists.wpkg.org<br>
> </font></tt><a href="http://lists.wpkg.org/mailman/listinfo/wpkg-users"><tt><font size=2>http://lists.wpkg.org/mailman/listinfo/wpkg-users</font></tt></a><tt><font size=2><br>
</font></tt>