Hi Keith, On 15.03.2010 23:58, k.e.jo...@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 ------------------------------------------------------------------------- wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/ _______________________________________________ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
