On Fri, Dec 19, 2008 at 05:45:01PM -0800, Bart Smaalders wrote: > Instead, the IPS architecture requires software to be largely > self-assembling; changes in configuration are either detected at boot > time or the appropriate SMF services are restarted in the case of live > installation of packages. [In the few cases when this is not possible > due to assembly being needed for boot, the required support is being > built into IPS directly; such cases are actually rare].
Note that it's important to specify the relationships between pkgs providing such SMF services and pkgs using them. For example: an isolated self-assembling pkg could deliver its own SMF service for self-assembly, but a pkg delivering a "plugin" for a larger framework should should typically have the plugin pkg deliver a registration for an SMF service delivered by the framework. Dependency issues arise. For example: the SMF service for a self- assembling pkg will [necessarily, at least when the image is not booted] be deleted before it has a chance to run and undo assembly at pkg remove time. That is the reason for separating the service providing self-assembly from the pkg needing it in the case of plugin frameworks -- if you remove a plugin pkg, the framework remains and can detect this (e.g., see my SVR4-scripting->IPS prototype) and do the Right Thing. But a self-assembling pkg that needs removal-time actions taken and which does not fit into any larger framework is screwed. Such a pkg could always [at self-assembly time] create a service that IPS does not know about and which will detect removal of the pkg, perform its removal actions, and then delete itself. So it seems to me that we need to: a) define and implement native (though OS-specific) IPS actions for generic pkg needs wherever possible; b) describe the framework/plugin dichotomy in the IPS best practices docs; c) define, document and deliver services for Solaris plugin frameworks that pkgs delivering plugins for can use, but only for frameworks where (a) is somehow inappropriate; d) provide tools for creating self-deleting SMF services. I've a prototype of (d) lying around, btw. (b) is a pattern that has been discussed extensively. Are we ready to declare it a best practice? To get to (c) we need to first decide what all (a) will cover. Cheers, Nico -- _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
