Trevor Watson wrote: >> If that can be reasonably detected, yes, it should be reported as a >> failure. > > It will be reported as a failure - most likely your system/container > will fail to boot or will panic at some point. I count that as a failure > report :)
That sounds a great deal less user-friendly than the equivalent errors that I might get from rpm or pkgadd. >> It's all part of "get me my darned application so that I can do the >> work that I really want to do". > > I think you are mixing up contexts here: applications vs services or > system bits. To some extent, yes. *Mostly*, I don't think there's a big difference. However, my personal perspective at the moment is as an application provider; how the OS gets installed is of no interest to me (when wearing my current hat). > In the case of an application - if it needs specific (ie not generic > actions such as update GNOME menus/cache/etc) configuration in order to > get it to work, then you could either write your own installer for it I thought one of the goals was to eliminate custom installers. > or create an SMF service which automagically creates a default > configuration in a one-off run. ... which means that failures are reported poorly. > For system type things, IPS delivers the bits, some actions get fired > off to do the necessary install and that's it. If it fails after that, > then that is not an IPS problem (unless, of course, it is a bug in IPS). If you constrain IPS's scope, sure. That's the question. There are classes of failures that will be clearly and cleanly reported by pkgadd and rpm, what will be reported quite poorly in an IPS world. > I think Shawn perhaps over-stated the bit about IPS knowing that a > service won't start or maybe I'm missing something. Certainly in the > case where a package is being installed in an not-running zone, then IPS > cannot reasonably know that any particular service will not start on > boot, but when the zone comes up, svcs -x should give some indication > (in theory). Sometimes it can. If it wasn't able to add an entry to a table (and here I'm not immediately coming up with the combination of (a) something that needs an entry added to a table and (b) has clear failure cases and (c) is applicable to a zone, but with research I'm confident I could find a case), then that's a failure that pkgadd or rpm would immediately report, that IPS (as it seems to be scoped) would defer to zone-boot and report in an obscure log file. > You keep saying "software management subsystem" which to me implies > something more than just package management. Perhaps. I thought it was all package management, but the local terminology here seems to have constrained "package management" to little more than laying down the files, so I had to come up with a broader term that covered the entire soup-to-nuts process. > Anyway, I don't think this thread is going anywhere, so this will be my > one and only contribution to it. That's my fear too. I suspect that the result will be that it will be clarified that IPS's scope is quite limited, in some areas significantly more constrained than pkgadd or rpm. Wearing my application provider hat, I'll work around that, probably by writing my own installer. Wearing my technologist hat, I'll be disappointed. _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
