Hi, Al Hopper p????e v ne 16. 09. 2007 v 12:42 -0500: > On Sun, 16 Sep 2007, Shawn Walker wrote: > > > 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. > > Yep - an interesting suggestion and I've already got Lua on my "to > try" list. The benefit of a more powerful scripting engine is that it > allows the developer to express the problem specific domain in > powerful and easily expressed/manipulated data structures - unlike > shell scripts. >
Only side note, are we sure that people will learn some special language just to create package for opensolaris? Best regards, Milan
