On 16/09/2007, Paul Armstrong <sunsolve at otoh.org> wrote: > > Mike Gerdts wrote: > > > On 9/13/07, Danek Duvall <danek.duvall at sun.com> > > wrote: > > In most cases, these sorts of actions can be > > postponed until either the > > service is started (for a simple case) or the machine > > is rebooted. Very > > few third-party packages should need to perform > > unique actions before > > the machine reboots. > > > > The problem is that getting scripting correct is > > difficult enough when > > one is talking about running in a normal context. > > Getting the scripting > > ight when we're modifying a local zone of a diskless > > client on an > > alternate architecture down-reved boot server is > > downright hard since > > so much of the installation environment affects the > > script... we want to > > defer these sorts of actions until the service > > starts. > > It would seem to me that scripting during a service restart is no better than > a package (and possibly worse). Once you've run the script you're in an > undefined state and if a package backout occurs then you're in an even more > undefined state as there's no way of triggering script backout. >
I don't think you're in any more of an undefined state outside the packaging process than during to a certain extent. If only because that is the same problem that packages create now with their scripts, they can do things that the packaging system by itself won't know how to undo. That's why I think Danek's suggestion about integrating functionality scripts need into the packaging system and making them use it instead of being able to do their own thing is preferable. This might be a great case for integrating small and fast for scripting that's easily "sandboxable," like Lua. -- Shawn Walker, Software and Systems Analyst binarycrusader at gmail.com - http://binarycrusader.blogspot.com/ "Beware of bugs in the above code; I have only proved it correct, not tried it. " --Donald Knuth
