Hi "grubi", Thanks for your comments. Your suggestion seems to offer the same possibilities as my fist proposal. However I like it more than my first proposal since it uses the same states (true/false/delayed) on both levels while adding just one new value "delayedPackages" to the command level. I will think about the best way to implement it. br, Rainer > -----Original Message----- > From: grubi [mailto:CAGYKZCNMKSY at spammotel.com] > Sent: Donnerstag, 29. November 2007 10:24 > To: 'Tomasz Chmielewski' > Cc: 'wpkg'; 'Rainer Meier' > Subject: Re: ++Mailshell: RE: [wpkg-users] 1.0rc1 - reboot > > Rainer Meier schrieb: > > Hi Rainer, > > thank you for thinking about the reboot delayed thing again. > > > 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. > > > I have to agree to most of what you said, however the admins > are able to > do similar things > with the current version right now by delaying reboot on the command > level. So to give them > more flexibility is not a bad thing in general if this > function is not > the default behavour. IMHO > you could not blame the devs for a properly operating feature you > explicity choose and not > understand it entirely. A disclaimer about the consequences > in the docs > would be a good idea. > > What do you think about the following: > > package level reboot: > > true -> always reboot ignoring command level result > false -> never reboot ignoring command level result > <not set> -> command level is controling behavour > delayed -> reboot after all packages are processed ignoring command > level results > > command level reboot: > > true -> immediate reboot > false -> no reboot > delayed -> reboot is delayed after all commands > delayedPackages -> reboot is delayed after all packages are processed > > Regards, > grubi > |