[wpkg-users] Suggestion: upgrades from specific revisions

[Rainer Meier]

Hi Ralf,

Ralf Lederle wrote:
> Hi,
> 
> I think it would be a good thing, if you could define different upgrade
> commands for upgrades from specific revisions.
> 
> For example: if you actually want to upgrade Adobe Acrobat 9, you first need
> to uninstall it, install it again and then apply 4 patches, which takes quite
> a lot of time. On machines, where the actual revision is installed, applying
> only one new patch would be sufficient.
> 
> I have something in mind like this:
> 
> <upgrade fromrevisionlessthan="5" cmd="..."/>
> <upgrade fromrevision="5" cmd="..."/>
> <upgrade fromrevisiongreaterorequalthan="6" fromrevisionlessorequalthan="8"
> cmd="..."/>
> <upgrade fromrevisiongreaterthan="8" cmd="..."/>
> 
> What do you think about this?

I mainly agree to Malte. Such an extension would make package definitions much
more complex. Also in terms of testing since every upgrade path might have
different commands and has to be tested independently.

In addition most installers include sufficient "intelligence" to upgrade from
basically any previous version.

In your example (Adobe Reader) I never had to uninstall a previous version up to
now. Just installing the new version worked pretty well.

I use a bunch of scripts to deploy Acrobat Reader (see attached archive). I just
add the patches to the unattended-postinstall.cmd script which is run right
after installing the basic Acrobat Reader version.
In fact re-running the basic installer was never a problem since it terminates
quite early (assuming you extracted the bloat exe installer to MSI) if exactly
this version is already installed on the machine. So actually only the updates
get executed.

The solution outlined by Malte to use dependencies is a very valid proposal too.
It allows you to define each update in an independent package and then WPKG
justs adds this update when you assign it to the profile. There is only one
small drawback that on minor (not patch) version upgrade you will most probably
remove the updates from the profile. This makes WPKG try to uninstall the
updates and then upgrading the base Adobe Reader package. No big deal I think
anyway since the updates do not need to specify any uninstall commands.


The request you outlined above was initially asked by more people already
(mainly users new to WPKG and automatic/silent deployment). I think most users
started to notice then that just re-installing the new version (without
initiating a remove) is sufficient for 99% of the packages. If not, then you can
 still wrap your installation into a small CMD script which can also detect the
exact current version and perform the necessary steps to upgrade the application
to the desired version.


With some applications you might even face the issue that some updates even
behave different if they are applied on a plain installation version (i.e.
installing version x.y.z on a fresh machine) or if they are applied on a patched
system (ie. installing version x.y on a fresh machine and updating to x.y.z).

All these special cases are very difficult to handle but in most cases you
don't. So most users will never have to deal with such things but just make sure
the install and upgrade commands do a silent installation of the latest version.
Just let the installer decide if an upgrade or fresh installation is done.

In case this fails due to dumb installers a wrapper script might help. Just
refer to a script/tool in your upgrade section. This script can do whatever
checks are required to determine the commands to be executed. In much more
detail actually than WPKG would ever be able to do it (since these exception
cases are highly application-dependent anyway.


If you really struggle on an installer which enforces such complex upgrade paths
then please let us know so we might able to provide some easy solution/work-around.

br,
Rainer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Acrobat-Package.7z
Type: application/octet-stream
Size: 10681 bytes
Desc: not available
URL: <http://lists.wpkg.org/pipermail/wpkg-users/attachments/20091019/752678d0/attachment-0002.obj>