James Litchfield wrote: > Having today tried to remove a large number of packages on S10U4 that > encompassed > enabled services, I'd dispute the assertion that one can disable the > services and > remove the packages. What I consistently saw was that disabling the > service would > occur (i.e. svcs <FMRI> would show it as disabled) but the package would > refuse > to be removed. It seems that the S10U4 r.manifest checks a couple of > properties rather > than the state of the service, decides that the service is still running > because those properties > are still "on" and refuses to remove the package.
Yes, there are other bugs open on implementation issues with the current behaviour. (6470919 might be what you're describing). But the question here is whether to change the behaviour entirely to take care of the disable as part of the package removal, rather than forcing an administrator to do so separately. liane > Mike Shapiro wrote: >> On Mon, Jun 02, 2008 at 02:50:11PM -0700, David Bustos wrote: >> >>> Quoth Peter Tribble on Fri, May 30, 2008 at 08:06:39AM +0100: >>> >>>> On Fri, May 30, 2008 at 1:19 AM, Liane Praza <liane.praza at sun.com> >>>> wrote: >>>> >>>>> We're seriously considering changing the behaviour of r.manifest when it >>>>> is invoked on an enabled (and running) service to simply do "svcadm >>>>> disable -s; svccfg delete", rather than failing with an error and >>>>> forcing the administrator to type svcadm disable before removing the >>>>> package. >>>>> >>>> Absolutely, I'm all in favour. >>>> >>> Allow me to play devil's advocate: Do you think it's possible that an >>> unsophisticated administrator will not understand the relationship >>> between the package he's removing and the services it delivers, and >>> would later regret the implicit disable & delete? >>> >>> David >>> >> That's a valid point, David, and I agree, but I think this is an >> example of factoring the problem at the right level. There are >> really two behaviors you want: >> >> a. A mechanism for removing something. That is what r.manifest does >> today, and it should disable and delete and not fail. >> >> b. A mechanism for asking the question "what happens if I remove you?" >> i.e. for asking for confirmation. >> >> The current package system has no interface to permit (b) -- i.e. to call >> into something in the package or intrinsically understand that. This is >> an example of where you want a separation between the internals and >> a particular presentation layer where it may or may not be appropriate >> to pop up some dialog box and say "this is running -- are you sure >> you want to remove it?" Clearly if nothing else decide the answer for IPS, >> since we certainly won't go back and address this in legacy packaging. >> >> -Mike >> >> > > _______________________________________________ > smf-discuss mailing list > smf-discuss at opensolaris.org
