[wpkg-users] [Bug 114] new parameter /force2 ?

bugzilla-daemon at bugzilla.wpkg.org bugzilla-daemon at bugzilla.wpkg.org
Thu May 8 19:01:08 CEST 2008


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.



More information about the wpkg-users mailing list