
<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">

<meta name="Generator" content="Microsoft Exchange Server">

<!-- converted from rtf -->

<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>

</head>

<body>

<font face="Calibri" size="2"><span style="font-size:11pt;">

<div>Hi,</div>

<div> </div>

<div> I’ve being trying to do some major upgrades to MS Office which meant sliding in new versions and adjusting dependencies for a bunch of add-ins. It’s been a lot more hard work than I’d expected because a majority of my packages are sooooo version specific

that changing one package meant completely re-writing a new package that was depending on it, creating new profiles to stage upgrades as a machine-by-machine rollout etc etc.</div>

<div> </div>

<div> I’ve been playing with turning InstallBeforeRemove on and off to see if it was adding complications. It was but, if I’m right, there’s some scope to actually eliminate it totally with some simple ideas.</div>

<div> </div>

<div> I’ve added some code to my copy of WPKG.JS so that before it removes a package it fetches the package definition from the server. I understand that there might be some knock on effects but it’s really simplified some complications for me and I’m beginning

to see that it might add some extra optimizations to WPKG.</div>

<div> </div>

<div> I’m thinking that rather than support the can-o-worms of that InstallBeforeRemove provides, it might be a more elegant strategy if, when removing a package;</div>

<div> </div>

<div>WPKG checked fetched the current definition of a package from the server;</div>

<ul style="margin:0;padding-left:20.25pt;">

<li>If it exists on the server, then it should use the server definition regardless of version (so that you get the flow of fixes to removal commands out neatly)</li><li>If it doesn’t exist on the server, then it should use the local version because it’s the only option you have  (the package is a zombie so it’s best to treat the local removal commands as the last resort or just zombie it immediately)</li></ul>

<div style="padding-left:20.25pt;"> </div>

<div> The-or-et-i-cally… there’s probably no need for WPKG to support installbeforeremove nowadays. The drive should be that there’s a neat and predictable way to anticipate how package versions changes work and then mimic the same effects by including install

commands in removal commands if they’re needed.</div>

<div> </div>

<div>Best Regards,</div>

<div> </div>

<div>Keith</div>

<div> </div>

<div style="padding-left:20.25pt;"> </div>

<div style="padding-left:20.25pt;"> </div>

</span></font>

<br clear="both">

___________________________________________________________<BR>

This email has been scanned by MessageLabs' Email Security<BR>

System on behalf of the University of Brighton.<BR>

For more information see http://www.brighton.ac.uk/is/spam/<BR>

___________________________________________________________<BR>

</body>

</html>