<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
I go a step further now - our commercial LAN has a 'CLEAN' build PC which is used to create and test packages. This PC has an image of a clean XP build on a hidden partition so we can roll back to this very quickly.<BR>
<BR>
Since starting with WPKG I have setup an old but more than adequate test PC - I have it in a seperate profile so I can test package rollouts and installs very easily.<BR>
<BR>
You could even look into a virtual PC as this is pretty easy to do and also means you can start again with a clean install of the OS by re-loading a clean image.<BR><BR><BR> <BR>> Date: Sat, 21 Feb 2009 11:40:33 +0100<BR>> From: r.meier@wpkg.org<BR>> To: gaio@sv.lnf.it<BR>> CC: wpkg-users@lists.wpkg.org<BR>> Subject: Re: [wpkg-users] Trying out package upgrades before general roll-out of package<BR>> <BR>> Hi Marco<BR>> <BR>> Marco Gaiarin wrote:<BR>> > Mandi! Robin Roevens<BR>> >> We have a general policy here that any new software update/-grade has to <BR>> >> be tested by 4 to 5 people for some time before it is deployed over all <BR>> >> affected computers..<BR>> > <BR>> > Good policy! ;-)<BR>> > <BR>> > <BR>> >> But I'm having trouble to do that with WPKG.. :<BR>> > <BR>> > WPKG does not support this, because the package version/revision are<BR>> > not considered when processing package list, eg there's no way to have<BR>> > the same package with two versions.<BR>> > I've proposed some month ago to add this, and to add the ability to<BR>> > (using a debian term) 'pinpoint' a particular revision.<BR>> > <BR>> > <BR>> > There's indeed a hackish but working solution: edit the .XML package<BR>> > recipe upgrading all stuff apart package revision, then edit the<BR>> > %SYSTEMDIR%\wpkg.xml status database of these 4/5 clients, go to the<BR>> > recipe entry and subtract 1 to the package revision.<BR>> <BR>> I actually prefer another (much less "hackish" solution). I just<BR>> configure my test-systems to use another WPKG installation (might be on<BR>> the same share). Then you can simply upgrade the package on the<BR>> "testbed" installation of WPKG and simply copy over the package<BR>> definition as soon as you know it works. You can even use the same<BR>> software directories/paths if you use the version number within the<BR>> directory name.<BR>> <BR>> For example<BR>> %SOFTWARE% pointing to \\server\software\<BR>> <BR>> Then put two versions of a program into this directory:<BR>> \\server\software\Pidgin v.2.5.3<BR>> \\server\software\Pidgin v.2.5.4<BR>> <BR>> Now install two WPKG versions:<BR>> <BR>> \\server\wpkg\wpkg.js<BR>> \\server\wpkg\packages\pidgin.xml <-- points to Pidgin v.2.5.3<BR>> \\server\wpkg\...<BR>> <BR>> \\server\wpkg-testbed\wpkg.js<BR>> \\server\wpkg\packages\pidgin.xml <-- upgrade test for Pidgin v.2.5.4<BR>> \\server\wpkg<...<BR>> <BR>> <BR>> This way you can simply test the package on your testbed machines<BR>> (configured to use 'wpkg-testbed'). When you finished testing just copy<BR>> pidgin.xml over to \\server\wpkg\packages\ and it will become productive.<BR>> <BR>> This way also allows you to test new versions of wpkg.js and other<BR>> modifications without affecting productive users.<BR>> <BR>> Sometimes it's not necessary to introduce too much complexity into a<BR>> program (wpkg.js) when there is a simple solution provided by the<BR>> operating system already.<BR>> <BR>> <BR>> By the way. I am thinking/workging on an extension of WPKG where it<BR>> would be possible to have multiple versions of a package defined in the<BR>> package database and then WPKG either selects the latest one or lets you<BR>> specify a specific one within the profile. However I am personally not a<BR>> friend of this solution because the solution outlined above gives you<BR>> more flexibility like full wpkg.js separation as well as diffetent<BR>> configuration (e.g you might want to use different config.xml / log<BR>> levels on testbed) without even a need to introduce any complex code<BR>> into wpkg.js which potentially creates problems. Every feature<BR>> implemented needs to be supported and fully tested for each following<BR>> release. As more complexity is added as more difficult it gets to<BR>> implement new things or even fix bugs in existing code.<BR>> <BR>> So give the solution outlined above a try.<BR>> <BR>> br,<BR>> Rainer<BR>> -------------------------------------------------------------------------<BR>> wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/<BR>> _______________________________________________<BR>> wpkg-users mailing list<BR>> wpkg-users@lists.wpkg.org<BR>> http://lists.wpkg.org/mailman/listinfo/wpkg-users<BR><br /><hr />Share your photos with Windows Live Photos - Free <a href='http://www.microsoft.com/uk/windows/windowslive/products/messenger.aspx' target='_new'>Try it Now!</a></body>
</html>