Laszlo (Laca) Peter wrote: > Sorry about the delay... > > On Mon, 2008-04-14 at 00:07 -0700, Danek Duvall wrote: >>> This is doable for these examples, I guess. It is the expectation >>> that each postinstall script is either eliminated by changing the >>> code such that no post-install processing is needed or becomes an >>> SMF service + an action that pings the service? >> Correct. If you find a case where that won't work, let us know, but we >> think this model should cover anything that's not required either for >> booting or really early in the boot sequence. > > I agree, it should work, since it basically pushes the > responsibility of postinstall tasks from the packaging system > onto smf. It makes sense, since it's a well defined and > controlled environment -- logs, timeouts, dependencies. > Much better than what we have now. > > I'm not sure how preremove scripts can be substituted, but I > can live without them for now. > > So I started thinking about how to implement an smf service > that imports the gconf schemas. What I'm trying to achieve > is that the service only does anything at system boot, if > there are new schemas installed or updated since the service > last imported them into gconf. Will the IPS action that > pings my service set a property or something to let the > service know that it has work to do? >
Well, one very simple model that comes to mind is having the (transient) service touch a file when it updates successfully; this would run at boot, stat the file and the schemas and decide there was nothing to do. Any new schemas delivered would have a timestamp later than that file, and cause the transient service to do the necessary work, perhaps only on the updated schema files if that makes sense/is possible. Note that unlike SVr4 packages, IPS doesn't attempt to preserve the build time of the packaged files; instead, the timestamps of the installed files reflect when they were installed. We could add a refresh action to IPS that could cause the same service to start if the new schemas were delivered on a live image; I'm still working out the exact details as only new actions are actually delivered when a package updates; the simplest method that comes to mind is adding an attribute to schema files that causes a refresh of the named service when the file is updated on a live image; something like refresh_fmri=svc:application/gnome/schema-update. All the refresh requests would be combined into one and executed after successful installation of the files on a live image. We're envisioning a similar technique to automatically rebuild catman and whatis after package installation. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
