> 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: [email protected]
Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgröße: 45
Geschäftsführer: Rainer J. H. Brandt und Volker A. Brandt
_______________________________________________
opensolaris-discuss mailing list
[email protected]
