Re: [osol-discuss] pkg scripts are evil :-) (was Some Why?-Questions)
Volker A. Brandt wrote: I completely agree. In fact, the way I would have done is: - don't ship any SVR4 pkg* tools with Nevada/OpenSolaris, ever SVR4 compatibility is still evolving, but I don't think I would have gone this route. - provide tools to semi-automatically convert package payload into IPS packages This already exists, although for publication (see man pkgsend). - provide tools to semi-automatically convert package scripts into one-off SMF services, i.e. services that execute once and then vanish again This is possible, but it is likely a ways off if it happens. -- Shawn Walker ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] pkg scripts are evil :-) (was Some Why?-Questions)
> When Stephen and Bart and company started talking about IPS leveraging > SMF, I suggested that it might be possible to keep the SVR4 pkg > pre/post install/remove script idea, add the "usual" SMF > start/stop/restart bits and automatically put the whole shebang into > the SMF framework at install time. Yes, indeed. The start/stop semantics is really quite similar to the install/remove script semantics, especially when you detach execution context from the installation context. What I mean by this that a common SVR4 pkg technique is to drop a disposable one-off script into /etc/rcN.d to do those things a pkgadd during Custom Jumpstart could not do. This is almost like a transient SMF service. > The response was "we don't do > scripting in pkgs - they should write their own SMF stuff > themselves" Funny, who would have guessed. :-) > I don't see leveraging SMF as a hack - heck, to me, inventing a 1-off > meta language to be used just for pkg scripts seems much more limiting > and hackish than leveraging SMF I completely agree. In fact, the way I would have done is: - don't ship any SVR4 pkg* tools with Nevada/OpenSolaris, ever - provide tools to semi-automatically convert package payload into IPS packages - provide tools to semi-automatically convert package scripts into one-off SMF services, i.e. services that execute once and then vanish again This would have reduced the initial number of apps for OpenSolaris a bit, yes. But many people would have woken up much sooner, realizing that they need to convert their packages to IPS in some intelligent way... > Maybe SMF needs to evolve the idea of "svcadm install/remove service" > so it would have a semantic place to put the pre/post install/remove > scripts I suggested this some months back, but it was rejected, because I wanted to introduce a new service type. > or maybe the first "enable" would simply notice that the > service had not yet run its install script; the result would be what > people are asking for without the problems associated with "wrong > context". We sort of have that, however the SMF service sticks around forever, which is not really a good thing. Regards -- Volker -- Volker A. Brandt Consulting and Support for Sun Solaris Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ Am Wiesenpfad 6, 53340 Meckenheim Email: v...@bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgröße: 45 Geschäftsführer: Rainer J. H. Brandt und Volker A. Brandt ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] pkg scripts are evil :-) (was Some Why?-Questions)
On Fri, Dec 18, 2009 at 3:36 AM, Volker A. Brandt wrote: >> What's needed is a supported mechanism to make it >> easy to do it right. > > +999 When Stephen and Bart and company started talking about IPS leveraging SMF, I suggested that it might be possible to keep the SVR4 pkg pre/post install/remove script idea, add the "usual" SMF start/stop/restart bits and automatically put the whole shebang into the SMF framework at install time. The response was "we don't do scripting in pkgs - they should write their own SMF stuff themselves" I don't see leveraging SMF as a hack - heck, to me, inventing a 1-off meta language to be used just for pkg scripts seems much more limiting and hackish than leveraging SMF Maybe SMF needs to evolve the idea of "svcadm install/remove service" so it would have a semantic place to put the pre/post install/remove scripts, or maybe the first "enable" would simply notice that the service had not yet run its install script; the result would be what people are asking for without the problems associated with "wrong context". -John ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] pkg scripts are evil :-) (was Some Why?-Questions)
Peter Tribble writes: > On Thu, Dec 17, 2009 at 11:15 PM, Alan Coopersmith > wrote: > > So the biggest gap in IPS is the long acknowledged lack of documentation & > > examples. > > That's not going to help - we have plenty of documentation and examples > for SVR4 scripting. What's needed is a supported mechanism to make it > easy to do it right. +999 -- Volker A. Brandt Consulting and Support for Sun Solaris Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ Am Wiesenpfad 6, 53340 Meckenheim Email: v...@bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgröße: 45 Geschäftsführer: Rainer J. H. Brandt und Volker A. Brandt ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] pkg scripts are evil :-) (was Some Why?-Questions)
Peter Tribble wrote: > > So the biggest gap in IPS is the long acknowledged lack of documentation & > > examples. > > That's not going to help - we have plenty of documentation and examples > for SVR4 scripting. What's needed is a supported mechanism to make it > easy to do it right. BTW: A scripting meta language could help to avoid things that do not belong into scripts being called at install or deinstall time. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] pkg scripts are evil :-) (was Some Why?-Questions)
Shawn Walker wrote: > Peter Tribble wrote: > > IPS ought to do this right, and is pretty much there because it actually > > does have the framework to do everything correctly, but claims that > > scripting is forbidden and therefore doesn't provide the public hooks, > > again forcing every script writer into carrying the responsibility > > themselves. > > We don't claim scripting is forbidden, just scripting during packaging > execution context :) > > You can script all you want with SMF. This looks to me like a hack but not like a solution. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] pkg scripts are evil :-) (was Some Why?-Questions)
On Thu, Dec 17, 2009 at 11:15 PM, Alan Coopersmith wrote: > Peter Tribble wrote: >> But that problem arises not because SVR4 packaging supports scripting >> but because it only does so badly. What's needed is: >> >> 1. For the packaging system to fully support scripting as a first-class >> citizen. Which could include actually providing the most common >> functions as builtins. >> >> 2. For all scripts to be written assuming they're running in the live >> context, which is easy to do and the only place most script >> writers will bother to test. >> >> 3. For the packaging system to itself take on the responsibility of >> ensuring that scripts are run in the correct context. >> >> SVR4 fails here because it shirks the responsibility, passing it onto >> every script writer. But that wouldn't be terribly hard to fix. >> >> IPS ought to do this right, and is pretty much there because it actually >> does have the framework to do everything correctly, but claims that >> scripting is forbidden and therefore doesn't provide the public hooks, >> again forcing every script writer into carrying the responsibility >> themselves. > > Actually that's pretty much what IPS does, it just leverages SMF as the > mechanism for ensuring that custom scripts are run in the correct context, > using actuators to start the SMF service immediately after package > installation > or allowing SMF to start it on first boot if not installing to the live image. As I said, IPS is pretty much there - it has the mechanism built in, it just doesn't provide a mechanism for scripters to leverage. > So the biggest gap in IPS is the long acknowledged lack of documentation & > examples. That's not going to help - we have plenty of documentation and examples for SVR4 scripting. What's needed is a supported mechanism to make it easy to do it right. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] pkg scripts are evil :-) (was Some Why?-Questions)
On Thu, Dec 17, 2009 at 11:12 PM, Shawn Walker wrote: > Peter Tribble wrote: >> >> IPS ought to do this right, and is pretty much there because it actually >> does have the framework to do everything correctly, but claims that >> scripting is forbidden and therefore doesn't provide the public hooks, >> again forcing every script writer into carrying the responsibility >> themselves. > > We don't claim scripting is forbidden, just scripting during packaging > execution context :) But "a no scripting" zone has passed into folklore. IPS certainly doesn't *provide* a scripting environment. > You can script all you want with SMF. SMF isn't a scripting environment. The packaging system needs to bridge the gap between the script that does the work and the mechanism to execute it, rather than expecting everyone to reinvent the wheel. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] pkg scripts are evil :-) (was Some Why?-Questions)
Peter Tribble wrote: > But that problem arises not because SVR4 packaging supports scripting > but because it only does so badly. What's needed is: > > 1. For the packaging system to fully support scripting as a first-class > citizen. Which could include actually providing the most common > functions as builtins. > > 2. For all scripts to be written assuming they're running in the live > context, which is easy to do and the only place most script > writers will bother to test. > > 3. For the packaging system to itself take on the responsibility of > ensuring that scripts are run in the correct context. > > SVR4 fails here because it shirks the responsibility, passing it onto > every script writer. But that wouldn't be terribly hard to fix. > > IPS ought to do this right, and is pretty much there because it actually > does have the framework to do everything correctly, but claims that > scripting is forbidden and therefore doesn't provide the public hooks, > again forcing every script writer into carrying the responsibility themselves. Actually that's pretty much what IPS does, it just leverages SMF as the mechanism for ensuring that custom scripts are run in the correct context, using actuators to start the SMF service immediately after package installation or allowing SMF to start it on first boot if not installing to the live image. The most common functions are builtin actions, like the one to install a device driver. So the biggest gap in IPS is the long acknowledged lack of documentation & examples. -- -Alan Coopersmith- alan.coopersm...@sun.com Sun Microsystems, Inc. - X Window System Engineering ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] pkg scripts are evil :-) (was Some Why?-Questions)
Peter Tribble wrote: IPS ought to do this right, and is pretty much there because it actually does have the framework to do everything correctly, but claims that scripting is forbidden and therefore doesn't provide the public hooks, again forcing every script writer into carrying the responsibility themselves. We don't claim scripting is forbidden, just scripting during packaging execution context :) You can script all you want with SMF. Other frameworks, hooks, or options may present themselves in the future as the project progresses. -- Shawn Walker ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] pkg scripts are evil :-) (was Some Why?-Questions)
On Thu, Dec 17, 2009 at 9:53 PM, John Plocher wrote: >>> The better question is why someone is doing something >>> so broken in the first place. >> >> There is nothing broken about being able to consistently and repeatably >> create databases via packages. > > If you can do so in a way that reliably does so, then there is no problem. > Unfortunately, given the diverse environments that pkgs are expected to be > installed into, the constraints on such pkg scripts are pretty severe. > Having written (and rewritten and re-rewritten) packages to do stuff like > this, I can almost guarantee that your package postinstall/preremove scripts > will fail chaotically and irreversibly in some relatively common > environments, like zones (branded or otherwise), cross-architecture diskless > servers and live upgrade (aka pkgadd -R..) - i.e., environments where the pkg > runtime execution context is NOT the same as the target environment. But that problem arises not because SVR4 packaging supports scripting but because it only does so badly. What's needed is: 1. For the packaging system to fully support scripting as a first-class citizen. Which could include actually providing the most common functions as builtins. 2. For all scripts to be written assuming they're running in the live context, which is easy to do and the only place most script writers will bother to test. 3. For the packaging system to itself take on the responsibility of ensuring that scripts are run in the correct context. SVR4 fails here because it shirks the responsibility, passing it onto every script writer. But that wouldn't be terribly hard to fix. IPS ought to do this right, and is pretty much there because it actually does have the framework to do everything correctly, but claims that scripting is forbidden and therefore doesn't provide the public hooks, again forcing every script writer into carrying the responsibility themselves. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
