On Tue, Jun 09, 2009 at 03:38:46PM -0700, Bart Smaalders wrote: > Nicolas Williams wrote: > >On Tue, Jun 09, 2009 at 11:52:14PM +0200, Darren Reed wrote: > >>One might ask the very same question of using SMF for that task. > >>How can SMF assemble a file it has never seen before? > > > >The pkg author provides the start method that knows what to do. > > > >>Why can we teach SMF to do this but not pkg? > > > >IPS could have it's own SMF-like actuator concept. It'd be replicating > >much of the same functionality that's already in SMF. I think that'd be > >cleaner, actually, but it'd also require lots more work. > > This would imply that anyone adding new stuff to be merged > would have to add code to the packaging system, and the packaging system > would have be upgraded often.
Well, no. What I had in mind was a generalization of that SMF service I prototyped for SVR4 pkg scripting -> IPS migration. Basically: a single SMF service to run all boot time self-assembly. Each pkg would deliver its self-assembly "jobs" (instead of self-assembly SMF services) via an IPS action that does the Right Thing (meaning: queue up the jobs, possibly by dropping them into a directory where they will be found by the IPS service that runs them). The nice thing about such an approach is this: the self-assembly actuator is not OS-specific, so IPS packaging can be less OS-specific. The problem with that approach is that you then need to implement an interface by which to see the status of each such job, and which can handle dependencies -- something SMF already has, so this would be code duplication, to a point. Nico -- _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
