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 ------------------------------------------------------------------------- wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/ _______________________________________________ wpkg-users mailing list [email protected] http://lists.wpkg.org/mailman/listinfo/wpkg-users
