[wpkg-users] InstallBeforeRemove and dependencies in complex environments vs having WPKG refreshing uninstall commands from the server .
r.meier at wpkg.org
Wed Mar 11 16:17:55 CET 2015
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
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.
More information about the wpkg-users