Any comments on this? thx, --emk -------- Original Message -------- Subject: [pkg-discuss] delivering smf services for configuration purposes Date: Tue, 02 Dec 2008 08:55:46 -0800 From: Ed McKnight <[EMAIL PROTECTED]> To: pkg discuss <[email protected]>
I have a core product with optional components. One or more optional components can be installed with the core product or installed later, and removed separately or along with the entire product. When an optional component is installed/removed it needs to be registered/unregistered with the system. Formerly this was done in postinstall/preremove. I'd thought that I could convert the registration to a smf service (with workaround for not being able to tell the service *which* component is requesting to be un/registered), where delivery/removal of the reg file in the optional package calls refresh() on the service, but am hitting a significant block. The registration service would be delivered by the core product. Since each optional component depends upon the core, if the user uses pkg(1) or PackageManager to install an optional component, then core gets pulled along into a single Plan. It appears that when the refresh of the service is invoked under the optional package, there is no guarantee that the service will have been already installed. Even if it has been installed, and its manifest says it is to be enabled immediately, there is still a delay between the manifest-import and the service coming online and there appears to be no guarantee that it will be enabled in time to be refreshed. This leads to install failures of the optional component. Similarly, on 'pkg uninstall' if the core is being removed at the same time as an optional component, when the optional component calls the service to do unregistration, there's no guarantee that the service hasn't already been disabled by the removal of core. It's looking to me as though services that may be needed within a Plan, cannot be delivered in that same Plan. Am I missing something here? Now I believe that I need to switch to a 'configure on first use' model for these optional components. This means that while under postinstall/preremove the configuration actions would be taken exactly once and at exactly at the right time, now I'll be constantly checking to see if configuration is needed. Seems like an efficiency step backwards. This also means that porting packages from SVR4 to IPS means modifying the product itself. ?? thx, --emk _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
