Speaking as both a developer and an administrator, I heartily endorse such a change.
As a developer, I don't want to have to write error-prone package scripts. As an administrator, darn it, I told you to uninstall the service, don't tell me something rote that I have to do to get it uninstalled. (Now, if disabling it will disable some still-installed service, *maybe* that would merit a failure. I might argue that in that case there should have been a package dependency that would preclude removing the package. If the convention is that there is a package dependency, then I guess I'd say to go ahead with the disable - the administrator has already chosen to override the package dependency.) Liane Praza 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. > > I expect service developers will be pleased with this, as they'll no > longer implement this logic in their own packaging scripts. Anyone else > have any concerns about such a change? > > (The IPS folks are planning the same approach for their SMF action.) > > liane > _______________________________________________ > smf-discuss mailing list > smf-discuss at opensolaris.org >
