[wpkg-users] (no subject)

[Rainer Meier]

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