On 12/ 8/10 02:49 PM, Ethan Quach wrote:
On 12/08/10 13:46, Dave Miner wrote:
On 12/ 8/10 04: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.
The problem with applying that to Scott's proposal is that it leaves
the package unverifiable, i.e. "pkg verify" will report it as unclean.
Not of the file we're overwriting is designed as an editable file though
right?
So they can only have one finish script? And what if they need to be
able to have different finish scripts depending on architecture?
But I was even thinking that the suggested service would expose some
directory as its consumption area (like the site profile directory
does), and we'd just be placing unpackaged files in there.
The postrun service that's been mentioned comes to mind.
Regardless, as I mentioned before, unpackaged files are not a great idea.
It seems far more beneficial to simply the existing tools and process.
-Shawn
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
