Nicolas Williams wrote: > On Tue, Jan 06, 2009 at 04:02:52PM -0500, Dave Miner wrote: >> Nicolas Williams wrote: >>> While the paragraph you quoted was about the SVR4 thing, the issue is >>> generic: how to communicate self-assembly failures. >> 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. > > svcs -xv and other UIs will certainly tell you about services that are > in maintenance mode. There exists nothing to tell you about how any SMF > service failures relate to image updates, and each such service had > better log useful messages to its stderr (which, incidentally, will not > be localized, as log messages usually aren't). > > A convention might well suffice. But something should be done. >
It seems that better reporting of service status, including localization of specific messages, is worth solving and then leveraging here. > At the moment svcs(1) output gives one no clues as to whether some > service is for software self-assembly. > Which seems merely a problem of updating the service manifest template section to provide the clarity you seek. > There were two parts to my question: one specific to a tool for legacy > SVR4 package scripting porting, the other generic to all self-assembly > in an IPS world. > > The answer to the latter can often be specific to the software being > installed (say, failure to assemble GNOME icons should be communicated > to the user at logon time). But a generic answer seems more > appropriate: I did an image update, rebooted, what's the status of > self-assembly? I don't want to have to try each piece of software to > find out! Whether any such UI is part of packagemanager or > updatemanager, or what have you, is another story. > I think we're violently in agreement that a general answer is appropriate; I just think it's a matter of leveraging and extending existing mechanisms, not inventing pkg-specific ones. Dave _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
