[wpkg-users] WPKG setups.

[Rainer Meier]

Hi Keith,

On 15.03.2010 23:58, K.E.Jones at bton.ac.uk wrote:
>  I've gone back over the last 2000 or so e-mails to the list since I was
> here last and many people now see to use the "package" definition to
> handle delivering a new version of software by changing the install
> commands and "bumping" the version.
> 
>  Is that a suggested practice nowadays?

As far as I remember it has always been the suggested practice. By incrementing
the package revision you instruct WPKG to perform an upgrade on systems where
the package is already applied in an older revision.


> I've always used the "bumping"
> technique to update a particular package's definition. All my *real*
> package version handling is done through profile dependencies (aka I
> have a "Firefox" profile which depends on a "Firefox 3.5" profile and if
> I upgrade I change that rather than the package itself).

This description is slightly confusing for me. I guess you're having a "Firefox
3.5" profile referring to a "Firefox" package. It could also be that you have
independent packages for different Firefox packages (e.g. "Firefox3" and
"Firefox35"). Unfortunately if you have multiple packages WPKG will have to
uninstall one if you switch to another one. But it's possible to do so because
WPKG will first do all uninstall tasks and then install the new ones.

However the usual way to do it is to use simple profiles which refer to a couple
of application packages. Only one package for each application exists Unless you
want to install/update/operate multiple versions in parallel. For most
applications this is not applicable since newer versions overwrite or update
older ones. For example installing Firefox 3.5 will remove Firefox 3.5
(respectively overwrite it). For MS Office it is possible to create an
"office2003" and "office2007" package and apply both to the host. So you can
deploy updates or uninstall them independently.

So the typical you should make sure that you have only one single package
defined in packages.xml (or in XML in packages/ sub folder) which deploys a
specific application. Then just always update the package definition,
install/upgrade/downgrade/remove commands and increment the revision.


>  I've had a problem with the "upgrade before install" option in wpkg
> recently and I was about to bug it but I just wanted to find out if
> things had changed before I relied on how I'm using it.

This might depend on your use case. The feature has been introduced in order to
simplify administration. The administrator does not have to take care if the
revision currently deployed on the client has valid uninstall commands or it's
probably broken. Admins can simply fix the package definition and make sure it
just works assuming this package revision is installed. WPKG will then first
make sure this version is installed before the remove takes place. This is
especially handy if you have a couple of clients out there and your package
initially deployed does not specify any remove commands and now you want to
remove the package. If there would be no remove-before-upgrade you would have to
update the package (increment revision, add appropriate remove commands) and
then roll it out to the clients. Unfortunately for this to work you would have
to wait until the update has been rolled out. In environments where clients
infrequently access the network this might take days, weeks or even months. Only
after all clients got the update you would be able to remove the package from
the profile and therefore WPKG would remove the software on next sync.
If one client missed the update to the fixed package revision it will fail to
remove the package since the revision installed on the client misses the remove
instructions.

Upgrade-before-remove works around this issue. Just fix up your package
definition, increment the version and remove the package from the profile. WPKG
will handle the rest. Next time a client connects it's upgrading the
application, applying new package definitions and immediately cleanly remove the
software in one step.


br,
Rainer