Hi, Shawn Walker p????e v ne 16. 09. 2007 v 16:28 -0500: > On 16/09/2007, Milan Jurik <Milan.Jurik at sun.com> wrote: > > 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? > > It's the same for every platform. Every platform has it's own > preferred installation and packaging method. There are even > differences in RPM macros, support, etc. between GNU/Linux platforms > that use RPM. >
No. It is not. Macros yes, of course, but the basic is shell. > The holy grail of ISVs everywhere has been a universal software > installation process, but so far, it has not come to pass. > > Besides, Lua isn't that obscure of a language, and has millions of > users worldwide (thanks to many software packages that use it and > companies like Blizzard who integrated Lua into World of Warcraft). > > As long as you have great tools around the packaging system, I don't > think it will matter that much. > Yes, for many packages you can ignore it. But e.g. many commercial ISVs are doing strange things in their install process (and those actions are special just for their SW). They will be really happy to invest their time to rewrite their scripts to some special language... Best regards, Milan
