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 -- Mike Shapiro, Sun Microsystems Fishworks. blogs.sun.com/mws/
