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 ------------------------------------------------------------------------- wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/ _______________________________________________ wpkg-users mailing list [email protected] http://lists.wpkg.org/mailman/listinfo/wpkg-users
