[wpkg-users] Remove does not start upgrade

[Rainer Meier]

Hi Marc,

> By the way is there any special reason why wpkg runs an upgrade before removal and not simply use the uninstall command from the server instead of the local one? This would eliminate the overhead of upgrading just to get the correct uninstall string. If the package isn't available on the server anymore wpkg should fallback to the local uninstall string.

Yes, there is a clear reason for this. WPKG has to assume that the
uninstall command in general is working fine. And therefore WPKG always
executes the commands associated to the package to be processed.
There are some applications where the uninstall command changes from one
version to the other. So exactly in your case this would create some
mess. A (outdated) package is installed locally and on the server side
there is a new version with a different uninstall command. Then you do a
manual remove of that version. Here WPKG has to assume the uninstall
string works.
The upgrade-before-remove process has been introduced to the
synchronization only to allow administrators to fix broken uninstall
strings remotely. Let's imagine that an administrator would like to
remove a specific package from a profile. This package is already
installed at xy machines but the uninstall string is wrong. So removing
the package from the profile would make WPKG to try uninstalling the
package - which fails. Then the administrator would have to add the
package again to the profile, update it, and now the real issue... the
administrator has to wait until all machines performed the upgrade (this
can take weeks and is hard to trace) before he would be allowed to
remove the package from the profile again in order to uninstall it on
all machines.

The upgrade-before-remove feature now allows the administrator to put a
fixed package on the server while removing it from the profile. Clients
will then automatically first upgrade and then properly remove.

In case the uninstall command changes from one version to another the
command on server side would probably fail to install the local version
on /uninstall operation which would for sure lead to bug-reports in our
Bugzilla quite quickly.

So there is a clear association
- Local metadata (wpkg.xml) is directly associate to installed software
- Remote metadata (packages.xml) is directly associated to available
packages

These two things should not be mixed or it could really lead to
confusing errors.


I am sorry about your "special case" but I think you can live with it.
You intend to do manual package removal (probably install/upgrade too)
and you know about this constraint that you need to upgrade your broken
package first. So I think it's no problem to do the upgrade first
(manually).

If you do it automatically the algorithm above just saves you some time
in some special cases.


br,
Rainer