On 12/ 8/10 01:33 PM, Ethan Quach wrote:
On 12/08/10 12:21, Dave Miner wrote:
On 12/ 8/10 02:48 PM, Scott Dickson wrote:
Looking at AI (and even bootable AI), finish scripts are sort of a
hassle.
It appears that if I want to have my own finish scripts, there's a lot
of overhead: I have to bundle it all up into a package, complete with
SMF manifest and activations, put it into my own repository, make sure I
install that package, and *then* do whatever I wanted the finish script
to do. Seems a lot.
What about having an almost empty package that I can add, for the sake
of discussion service/finish-script, that includes the SMF
infrastructure to make it execute at first boot (and only first boot),
along with a named exit that I can use for the payload. So, this package
provides a null script called /etc/init.d/finish-script, for example. I
can then either put my code there or make it call my code.
This really reduces the overhead in terms of development for adoption.
Having do build my own packages, using the distro constructor, or
anything like that is way too burdensome.
Or have I missed something really simple here?
Scott, we've been discussing ways we might make this process easier.
One thing I don't understand is how you're proposing to deliver the
contents of your hypothetical /etc/init.d/finish-script to an AI client?
We could probably use the <configuration> tag in the AI manifest to
carry this file over. Its unimplemented right now, but I could see that
this level of file is the type of thing it should support.
Delivering unpackaged files to the system is a bad idea. Wherever
possible, users should be directed to create packages instead.
When you deliver unpackaged files, you short-circuit a great deal of
mechanism that exists to ensure deterministic behaviour of installs.
-Shawn
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
