[wpkg-users] 1.0rc1 - reboot

[Rainer Meier]

Hi all,

Unfortunately I am quite busy now. But I will think about that and probably
come up with a solution on the weekend. 

> > Supporting reboot=delayed might cause packages depending on the one
which
> > requires a reboot to fail. Unfortunately such problems can be quite hard
to
> > trace. I already struggled over quite some packages which just quit the
> > installation in case there is an reboot scheduled.
> 
> Is it really so?
> 
> I imagine that reboot=delayed on a package level would just set some 
> internal variable; let's say DELAYEDREBOOT=true.
> 
> Upon exit, wpkg.js would check the value of that variable:
> 
>    if DELAYEDREBOOT set to true -> reboot, exit(3010)
> 
> How could it possibly do any wrong to package dependencies?

Well, doing this will not be a problem - it requires a new global variable
and a check after synchronizing. However I wanted to keep the number of
global variables smaller ;-).

But please think about the reason why a package usually exits with an exit
code which requires a reboot. Usually a file could not be replaced and will
be swapped at next reboot. So the installation is not complete (some files
not replaced/updated). A package which depends on the first wone might
depend exactly on the files which could not be swapped and will therefore
fail.
This is what I meant is "hard to trace". If a package is initiating such a
reboot process it will need to be treated as "successfully" installed for
the rest of the WPKG session - while it is actually not finished and even
package checks might still fail (they might just become true after reboot).

So it's quite a sensitivie change which will for sure also require handling
within the deepest core of wpkg.js (the installation function).

Of course we can blame it up on the package creator if he uses a delayed
reboot and then packages depending on the first one fail to install on first
try. However such administrators will blame it on the tool at the end.


> If any previous package schedules an immediate reboot, than 
> of course we 
> don't have to worry about DELAYEDREBOOT value anymore.

Yes, then a reboot is immediately initiated after that command (or after the
package, depending where the reboot is specified).


> If no previous package scheduled an immediate reboot, then with 
> reboot=delayed we schedule a reboot *after* all actions are done.
> 
> I don't see where it could do more harm than reboot=false.

Of course everybody is able to create such a situation on purpose as well by
setting reboot=false and ignoring all "reboot required" exit codes. But then
you need to catch 3010 exit codes from MSI installers _manually_ and you
know what you're doing. In case of "final reboot after all actions" this
connection might not be so obvious. So we might end up with bugzilla reports
saying that the package installation always fails on first/initial
deployment.


After all I think we can do it but I have to think about it without hurry to
trace all possible cases. I also think that the package reboot flag needs
the following values:
reboot=true -> reboot in any case after package installation
reboot=false -> never reboot (even if reboot=delayed on cmd level is
specified)
reboot= (or not set) -> no reboot by default / will reboot if reboot=delayed
is specified on cmd level
reboot=delayed -> reboot after all packages have been aplied but only if a
cmd set reboot=delayed
reboot=delayedAlways  -> reboot after all packages have been aplied (in any
case)

So the first two states will precedence to any reboot=delayed flag within
the cmd nodes.
The reboot=delayed will just postpone a reboot scheduled by any cmd node
using reboot=delayed on cmd-node level. In case a user wants to achieve a
delayed reboot in any case we need to be able to specify this as well. Here
I propose a "delayedAlways" rule.


As I said, I will think about it.

br,
Rainer