[wpkg-users] InstallBeforeRemove and dependencies in complex environments vs having WPKG refreshing uninstall commands from the server .

[Keith Jones]

Hi Rainer,

> -----Original Message-----
> From: Rainer Meier [mailto:r.meier at wpkg.org]
> Sent: 11 March 2015 15:18
> To: Keith Jones; wpkg-users at lists.wpkg.org
> Subject: Re: [wpkg-users] InstallBeforeRemove and dependencies in
> complex environments vs having WPKG refreshing uninstall commands from
> the server .
> 
> Hi Keith,
> 
> 
> On 10.03.2015 23:24, Keith Jones wrote:
> >   * 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)
> >   * 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)
> 
> Thanks for your suggestion, but this is very insecure way of handling
> packages and I would regard such an implementation as broken. WPKG
> should at no point in time mix between the package definition on local
> system and the one on remote system. Especially it should not start using a
> remote package definition which is different than the local one on local
> system state.
> The commands (install/upgrade/remove) of an application might have
> changed form one version to the next one and therefore using remote
> package definition and just applying them on local system could have
> unpredictable effects. Moreover when WPKG is run you don't have any clou
> how much different the version on local host is compared to the version on
> remote. It might be the same, direct predecessor or any earlier version.
>
> The only safe way is to first assure the client is on same version as latest
> package definition on server side. Which in turn means to upgrade before
> actually a clean remove is attempted.
> 
> If you like to allow direct remove without previous upgrade attempt then
> simply disable upgrade-before-remove in settings. However be aware that
> in case the client runs on a local version which cannot be properly removed,
> it might be stuck there. Just taking the servers-side package-definition
> where admin might fix some remove commands is not a good solution since
> the servere-side commands will take care to remove the latest package
> version properly but not necessarily work well with an outdated version.
> 
> Of course there will be situations in which it works, but it's just dirty and
> very likely to fail. Therefore WPKG in its current implementation only applies
> commands on the package it belongs to and not just fetching any newer
> package definition to apply it on outdated local software.
> 

  I really appreciate your time in commenting. I'm sorry that I'm so late in responding.
It's not only very busy here, but I've been scratching my head like crazy sorting out
how to respond.

 I understand exactly what you mean and it makes totally logical sense to me. I'm
finding it hard to reconcile that with some of the workflow I've been using though
to keep WPKG ticking along and it feels like there needs to be an alternative. 

 An example might help here :-)

 One of the issues I'm flushing through our system is a fix to a bad service pack for
Office 2010. In their infinite wisdom, Microsoft made SP1 (and SP2) add "Sharepoint
Workplace" without checking if it was previously installed. The end result is that
the usual removal commands leave it behind. Because it's left behind, OSE is left
behind and so are the entries in the uninstall keys that are usually used to detect it.
My package for Office broke badly :-(

 The problem was trying to work out whether to;

a) remove the existing upgrade node that installed SP2 and bump the version
- Hence also needing to re-write the install elements, modify checks and then
write bulletproof uninstall commands that coped with any machine that was using
older upgrade code because of being offsite.
b) leaving the upgrade code as it was and bumping the version
- Hence living with SP2 being re-installed and then writing bulletproof uninstall
commands.
c) Write a batch file to fiddle with installs
- Never really a good way of handling things :-)
d) Sliding change through via migrating to another package ID
- Complicated with dependencies also in mind to worry about.
e) Pick up on the bad uninstall elsewhere
- By fitting into an forth coming Office 2013 upgrade.

  When I was thinking through that, I realised that I was going to have to write
bulletproof uninstall commands anyway so perhaps it wasn't important that
WPKG went through delivering that using upgradeBeforeInstall. I think my
environment (lots of devices wandering on and off site as well as lots of static
computers) is not helping much. Everything I do, seems to push WPKG to be
very over-sensitive or under-sensitive to the workflow for up/downgrade
commands. Perhaps it's just my bad package design :-). Perhaps I've just got
two competing needs :-)

 Having said that last bit, I realise that this is most likely to be something that
I should approach a lot more supportively. I have test code, it shouldn't take
long for me to add it to WPKG as a switchable option and submit it for 
people to play with. The default setting will be to have it off, of course! :-)

 My apologies if I was over-enthusiastic. I was rather tired and I'm still wrestling
with log files to try and find a fault with my packages rather than a difference
in style/need.

Sincere regards,

Keith

PS: I guess you already know I love WPKG too (I've just read today's messages
And just wanted to echo another fan's words for the record) :-)

> br,
> Rainer
> 

 
> ___________________________________________________________
> This email has been scanned by MessageLabs' Email Security System on
> behalf of the University of Brighton.
> For more information see http://www.brighton.ac.uk/is/spam/
> ___________________________________________________________

___________________________________________________________
This email has been scanned by MessageLabs' Email Security
System on behalf of the University of Brighton.
For more information see http://www.brighton.ac.uk/is/spam/
___________________________________________________________