http://bugzilla.wpkg.org/show_bug.cgi?id=114 --- Comment #6 from Rainer Meier <r.meier at wpkg.org> 2008-05-08 19:00:46 --- OK, I had a quick look at the code and it seems that I was at least partially wrong about the full effect of the evil /force parameter. It does not operate on an empty settings file (wpkg.xml). Instead it executes the checks of every package to see if it is installed - the result is used as wpkg.xml. As a result also packages installed manually by the administrator are considered to be "installed". Used in conjunction with /synchronize this leads to software uninstall if the software is not within the profile. Well, sounds like a case I never actually thought about. So I started thinking about a parameter like /checkUnassigned. The difference is that it should not discard wpkg.xml but in addition verify the installation status of all other packages which exist in packages.xml. If one of them reveals true then it's added to wpkg.xml. A later synchronization will remove packages which are not within the profile. Packages which exist in a newer version are upgraded. Using this algorithm WPKG would remove packages from a system where the checks reveal true if the package does not apply to the profile. However in general I think this feature would be of very little use since it would only take care about packages which exactly match the version installed by the local user. For example if you use registry checks for Firefox you check for "Mozilla Firefox (2.0.0.14)". So WPKG would remove Firefox 2.0.0.14 during such a /checkUnassigned run. If the user installed Firefox 2.0.0.13 it will not be removed as WPKG does not detect the package to be installed (checks fail). At least using the algorithm I proposed above WPKG would not throw away its local wpkg.xml and could therefore detect if a package under WPKG control needs to be upgraded or not. The only difference to a normal /synchronize run would be that WPKG tries to detect if any of the packages which do not belong to the profile is installed as well and then it would remove it during synchronization. /checkUnassigned By default WPKG verifies only the packages assigned to the host. Using this switch WPKG will also check if any of the packages not assigned to the host are installed. Any additional package found will be added to the local package database. If used in conjunction with /synchronize every additional package found will be attempted to be removed. In general you should not use this switch unless you have really good reason to do so. Checking the installation status of every package is a quite expensive operation. Note: Conflicts with /force which takes precedence if both switches are used. So this feature could somehow be used if one has some kind of "no-go" software which he wants to make sure they are NOT installed at all. By creating a package and not adding it to any profile WPKG could verify on each run if this package is installed and remove it if found. However I still think this is a very very expensive operation to check _all_ packages on the server each time if it probably matches a software installed manually by a local user. The probability to detect exactly this version of the software is also decreasing its use. Of course quite general checks could be used to detect any version of Firefox for example checking for the firefox.exe binary. Unfortunately this decreases the stability of WPKG installation checks due to the fact that such a general check still returns true on systems where the user did a downgrade of the WPKG-deployed Firefox 2.0.0.14 to Firefox 2.0.0.13. WPKG could simply not detect it. So in such case I would personally prefer to create a 'firefox-remover' package with execute="always" and an install command which checks for Firefox and removes it as necessary. -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. |