On Thu, Nov 27, 2008 at 12:02:38AM -0800, Jordan Brown wrote: > There are plenty of good schemes for handling plug-ins, depending on the > exact nature of the application.
They all follow a pattern set by the packaging technology used. E.g., SVR4 pkgs use CAS and pre/postinstall/remove scripts. > The problem is that somebody has to fix the application to use one of > those schemes, and there are a zillion applications to fix and more > being created every day. The problem is easier to solve than you think. Over the Thanksgiving break I've been thinking about leveraging all the existing SVR4 class action scripts to do just that. Methinks we could programmatically create SMF services for IPS pkgs to ping by leveraging the existing SVR4 packaging in the various consolidations. - CASes would install into, say, /var/pkg/.../cas/ - pkgs delivering plug-ins would install the inputs to CASes into, say, /var/pkg/.../<plug-in-framekwork-pkg>/<plug-in-pkg>/<path> - pkgs delivering plug-in framekworks would track what actions have been run for install/removal in, say, /var/pkg/.../<plug-in-framekwork-pkg>/state/ - the SMF manifests and start methods would be generic We know the CASes will run on the booted image, and we know what environment they should run with. I've not prototyped this, but it seems simple enough. Post/preinstall/remove scripts would still have to be manually converted. There's 356 of those in ONNV. 243 of them deal with drivers and are easy to replace. I haven't looked at all of them, but I suspect that most can be replaced with simple IPS actuators; some can probably just go away (e.g., SUNWarc's?), some will need manual creation of CAS, some can be converted to fit into a plug-in system like the above (e.g., pkgs that edit crontabs), ... Nico -- _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
