[wpkg-users] Trying out package upgrades before general roll-out of package

[Rainer Meier]

Hi Marco

Marco Gaiarin wrote:
> Mandi! Robin Roevens
>> We have a general policy here that any new software update/-grade has to 
>> be tested by 4 to 5 people for some time before it is deployed over all 
>> affected computers..
> 
> Good policy! ;-)
> 
> 
>> But I'm having trouble to do that with WPKG.. :
> 
> WPKG does not support this, because the package version/revision are
> not considered when processing package list, eg there's no way to have
> the same package with two versions.
> I've proposed some month ago to add this, and to add the ability to
> (using a debian term) 'pinpoint' a particular revision.
> 
> 
> There's indeed a hackish but working solution: edit the .XML package
> recipe upgrading all stuff apart package revision, then edit the
> %SYSTEMDIR%\wpkg.xml status database of these 4/5 clients, go to the
> recipe entry and subtract 1 to the package revision.

I actually prefer another (much less "hackish" solution). I just
configure my test-systems to use another WPKG installation (might be on
the same share). Then you can simply upgrade the package on the
"testbed" installation of WPKG and simply copy over the package
definition as soon as you know it works. You can even use the same
software directories/paths if you use the version number within the
directory name.

For example
%SOFTWARE% pointing to \\server\software\

Then put two versions of a program into this directory:
\\server\software\Pidgin v.2.5.3
\\server\software\Pidgin v.2.5.4

Now install two WPKG versions:

\\server\wpkg\wpkg.js
\\server\wpkg\packages\pidgin.xml <-- points to Pidgin v.2.5.3
\\server\wpkg\...

\\server\wpkg-testbed\wpkg.js
\\server\wpkg\packages\pidgin.xml <-- upgrade test for Pidgin v.2.5.4
\\server\wpkg<...


This way you can simply test the package on your testbed machines
(configured to use 'wpkg-testbed'). When you finished testing just copy
pidgin.xml over to \\server\wpkg\packages\ and it will become productive.

This way also allows you to test new versions of wpkg.js and other
modifications without affecting productive users.

Sometimes it's not necessary to introduce too much complexity into a
program (wpkg.js) when there is a simple solution provided by the
operating system already.


By the way. I am thinking/workging on an extension of WPKG where it
would be possible to have multiple versions of a package defined in the
package database and then WPKG either selects the latest one or lets you
specify a specific one within the profile. However I am personally not a
friend of this solution because the solution outlined above gives you
more flexibility like full wpkg.js separation as well as diffetent
configuration (e.g you might want to use different config.xml / log
levels on testbed) without even a need to introduce any complex code
into wpkg.js which potentially creates problems. Every feature
implemented needs to be supported and fully tested for each following
release. As more complexity is added as more difficult it gets to
implement new things or even fix bugs in existing code.

So give the solution outlined above a try.

br,
Rainer