http://bugzilla.wpkg.org/show_bug.cgi?id=114 --- Comment #8 from Rainer Meier <r.meier at wpkg.org> 2008-05-08 22:17:18 --- Despite the fact that we are running off-topic (initial request was to discuss about a feature to remove installed packages which should not be there) I see some real issues when implementing something like an additional action="upgrade" attribute to checks. First of all the current architecture does not allow such kind of checks. But I don't want to say it's not possible. It just needs some more careful design while I am not sure if it's worth the effort. In fact we are clearly talking about broken installers here which do not upgrade silently when a previous version is already there. In addition your new proposal here is somehow incompatible with the proposed /checkUnassigned switch. If the /checkUnassigned switch would check the install status using the new <check.../> syntax then it probably would receive the code for "upgrade" which means "this package is already installed but it is outdated". What should WPKG do then? According to the /checkUnassigned description the package should be removed if it exists but should not be installed (not within the profile). Unfortunately if the install check returns this "update" state, then WPKG does not know if the uninstall strings (which are actually for the latest version on the server) can be used with such a previous version too. In general I would say WPKG should not try to execute the uninstall strings but just print a message to the logs (can be read by administrators to know such a package is installed on this machine). More issues/questions are coming up if we think about a generic implementation of the action="xxx" attribute. This attribute could have the following values: - install - upgrade - downgrade - remove but what if a user specifies something like <check type="logical" condition="or"> <check type="uninstall" condition="exists" path="Mozilla Firefox (2.0.0.13)" action="upgrade" /> <check type="uninstall" condition="exists" path="Seamonkey" action="install" /> </check> In such case the action might evaluate either "upgrade" or "install". To solve this actions could have priorities like: 1 default (by package version comparison) 2 execute remove 3 execute downgrade 4 execute upgrade 5 execute install So to me even in theory it looks quite complex and hard to control. In addition you would need to specify precise checks for each known version of this application which is a true headache. Quite a lot of effort just to detect if a package newly added to the profile needs to be upgraded (which would be done anyway on next package update). In case a package does not belong to the profile and the /checkUnassigned switch would be used then the package should be finally removed. Your addition would allow to execute an upgrade instead - on next synchronization it would be regularly removed. But again, this is a lot of change with a huge potential for bugs. As you can see such a change depends on a huge number of constraints while again it is only useful in some really rare cases where the installer is wrongly behaving. -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. |