Hi, Troy Hamilton wrote: > WPKG handles package and profile overlap just fine. As long as you > have your "checks" set up correctly, wpkg won't try to reinstall a > packages just because it's found in more than one applied profile.
It's not even about checks. WPKG builds a list of packages which apply to the current host where it is run. The list is unique regarding package IDs (a DB admin would say it's unique by the ID primary key). So you could refer to one single package as many times as you want from different profiles applied to a host, WPKG will try to install it only once. This reminds me to be careful when I am going to allow the same package id with different versions and a specific version to be applied to a profile. In such case it's much more difficult to handle the case where different profiles would refer to different versions of the same package. I think I am going to throw an error in such cases ;-) >> If I have 5 packages in one profile and 3 of them require reboot, If I set >> those three >packages to reboot=true, will it reboot after each package, >> come back up and process the >next one? Or will it recognize all three and >> just reboot once at the end? > > I'm going to defer to someone else on this one since I'm not 100% sure > about the order of precedence between reboot directives in packages, > on the command line, and in config.xml. > > Aside from that, though, when it does reboot, wpkg will continue > installing the next time the service starts or the script is run. Right, let me add a note that you might specify reboot=postponed to the package instead of reboot=true. This schedules a reboot after synchronization. So if you specify reboot=true WPKG will reboot the machine immediately after the package is installed. In your case (three packages specifying reboot=true) the machine will reboot three times in a row if all packages are installed during sychronization. Please note that WPKG will of course NOT reboot if the package is already properly installed. The reboot just takes place after install/upgrade/downgrade/uninstall command. So if it is enough to reboot after WPKG run completes, then you might change it to reboot=postpone. > I'm pretty sure that the install will continue with the user logged > in. The only problem is if the install calls for a reboot and the > user has already logged in and started working. Of course WPKG will continue to install. However there are more possible problems when the user already logs in and starts to work. Apart of possible reboots (which are not really often required) an upgrade command might fail if a crucial application files are locked because the user is currently running the program. To work around this problem you might insert taskkill calls to the package install/upgrade commands. However this could yield data loss if the user did not save... Some installers handle it properly if files are in use. They just schedule the replacement of the locked files to next reboot. > I'm very picky about short login times, so I run wpkg as a service > that I start manually from a cron job or with sc.exe. I am not using logon delay and I am quite happy with it at the moment. I am also using a Samba PDC with roaming profiles. It's quite uncommon that I have to deploy more than one update per day an usually I think WPKG already finishes before the profile is loaded and the user gets the chance to run some programs. In worst case (if the user really manages to lock some files) most installers just fail and exit with a special exit code. The package check after installation might fail too. So WPKG will just do another try on next reboot and might succeed then. 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
