Nicolas Williams wrote: > On Tue, Dec 23, 2008 at 08:50:36PM -0800, [email protected] wrote: >>> For example, my prototype for adapting SVR4 package scripting to IPS >>> completely ignores CAS and post* script failures. What else could it >>> do? Go into maintenance? But this service runs scripting for any SVR4 >>> pkg, so to stop running all of them on account of one failure seems too >>> blunt a technique. Better to update a pkg self-assembly status DB that >>> some UI(s) can interface with. >> You could implement this with a separate instance per-package that is >> under this serivce - that way, each package could individually go into >> maintenance. But again, this service seems more suited for third-party >> packages rather than the ones associated with the legacy WOS concept. > > While the paragraph you quoted was about the SVR4 thing, the issue is > generic: how to communicate self-assembly failures. > > Are you saying that we're not going to have any pkgs in > opensolaris.org/release that rely on SMF services to do the > self-assembly, that every such action will actually be a native IPS > action, such that there will be no self-assembly asynchronous to pkg > installation/removal? >
I don't think that's what David was saying at all. We already have such services in the WOS (application/desktop-cache/*) but by decomposing them to separate services or instances you can use SMF and notification methods built on top of it (I'll concede this is an area which could use work) for communicating the failures. Wedging that job into packagemanager or updatemanager (or pkg...) seems to be a case of reinventing that wheel. Dave _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
