http://bugzilla.wpkg.org/show_bug.cgi?id=114 --- Comment #9 from Jens Geile <jens.geile at mzbs.de> 2008-05-13 12:21:37 --- > 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. And where is the problem? Wasn't WPKG upgrading all packages before uninstalling them anyway if the revision on the server is higher than on the client? At least i kind of remember something like that. So update and then remove. Sounds fine to me. > 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). Looking at http://wpkg.org/Java _I_ get a headache. ;) > 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. Again, sounds fine to me. And shouldn't WPKG be able to upgrade and remove the package in just one run? I mean, it detects a lower version, upgrades, checks again and finds that the package is installed but not in the profile and uninstalls it. > 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. Well, if this <check ... action="..."> change is too much, at least for now, then at least it would be at least good to get the "uninstall software not in profile" feature. -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. |