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

[Rainer Meier]

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.

br,
Rainer