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 |