[wpkg-users] Checks prior to install

Rainer Meier r.meier at wpkg.org
Mon Oct 20 21:27:35 CEST 2008


Hi Michael,

Michael Mills wrote:
> I have always worked under the assumption that the checks worked prior
> to installation to see if the software was already installed, then again
> after to see that it really installed.
>
> I think my first assumption was wrong.  I don't seem to see anything in
> the output that supports my assumption.


Well, this is not entirely true. WPKG works in the following way:
- First WPKG checks if a package exists within the local settings file
(installed via WPKG already once)
- If the WPKG did already install this piece of software, then it uses
the local settings entry to determine if the command needs to be
upgraded or downgraded (WPKG package version mismatch)
- After executing the command (upgrade/downgrade) WPKG runs the checks
to verify if installation was successful

Your use-case of switching non-managed computers to managed is handled
by an additional algorithm. If a package is not installed by WPKG
(settings does not contain an entry of this package) WPKG first executes
the package checks to see if it is installed already. If the package
checks yield true (package not in settings file but installed already)
it is not re-installed but added to local settings file immediately.

I think this is exactly what you want. For example if you have a PC
which is not managed but Firefox, OpenOffice, Pidgin and such tools are
already installed, then just run WPKG. If the check for Firefox yields
true, then WPKG will write the firefox package to local settings file
(%SystemRoot%\system32\wpkg.xml) without actually executing any test.

I tested that several times on different machines. I set up all the
software manually and run WPKG - it detected all software to be
installed and did not execute any single install command but just
filling in the local settings file.

Starting from then WPKG will use the settings file to determine if a new
package on the server causes an installation, upgrade or downgrade.


Note: This algorithm has a small drawback (I already mentioned it within
a Bugzilla entry) which has to be accepted if this algorithm is used. In
case a check matches for multiple versions (e.g. you just do an
"uninstall" check on "Pidgin") WPKG cannot detect on first run if Pidgin
2.5.1 or 2.5.2 (btw. relased today) is installed. So if your package is
mentioned for Pidgin 2.5.2 and 2.5.1 is actually installed on the system
WPKG will not do an upgrade on first run. However when Pidgin 2.5.3 is
released and you update your package, then WPKG will do the upgrade to
2.5.3 then (no matter if 2.5.1 or 2.5.2 was installed before). I
considered this small "problem" to be acceptable in favor of having to
enforce re-installation of all packages on first run (even if they are
already installed).


So as a final word: Just make sure your checks correctly
detects/verifies the software installation. In that case WPKG will be
able to detect already installed applications on first WPKG run.


> If this is indeed not the way it works, I would like to request that
> maybe it should.  While managing new computers is fully functional,
> without detecting what's already on a machine, switching non-managed
> computer to being managed is more problematic.

No need to change, it is already handled like this.
But again, this applies only to package which have not been deployed
through WPKG previously (non-existing within local settings file).

br,
Rainer



More information about the wpkg-users mailing list