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 |