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.
Jim --- 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 > >
