Quoth Peter Tribble on Wed, Jun 04, 2008 at 07:45:19PM +0100: > On Wed, Jun 4, 2008 at 7:22 PM, David Bustos <David.Bustos at sun.com> wrote: > > Actually I believe Peter suggested that an unsophisiticated user would > > "blindly disable" the service. And if someone is willing to blindly > > disable a service, then there's no hope. > > There's no hope :-(
I presume you mean that everyone is willing to blindly disable a service which the packaging system has refused to delete because it's running. I disagree with that judgement, but I have no evidence. Well besides myself, I suppose. > (And not only will they blindly do it, they'll gripe and moan and tell > their friends how Solaris packaging isn't capable of obeying the simplest > and most obvious of instructions.) I don't think that should be a concern if the packaging system is sufficiently clear about why it's failing. > > But if someone isn't familiar > > with SMF, then that is his opportunity to say, "Hmm, I didn't know that > > this package delivered service X. > > And there's the problem. Why is the user removing this package? To get > rid of it and the functionality that it offers - including associated > services. > (Indeed, one might suspect that users might be trying to remove the > package specifically to remove the service.) So either the service is > explicitly and obviously associated with the package (the foobar service > and the foobar daemon), in which case the user ought to be expecting - indeed > wanting - the service to get zapped with the files, Right. A user who is removing a package in order to remove a service would not be surprised by the packaging system disabling the service. Is that 100% of cases, though? I doubt it. The case that comes to my mind is a junior administrator who was handed a list of packages to remove, without knowing which services they deliver. It's entirely possible that the proportion of these use cases is very small, but the injury could be large, and the benefit -- skipping a disable command -- seems very small to me. If the benefit addressed something larger, like data loss, or administrators choosing to deploy another operating system over Solaris, then my judgement would probably be different. All that said, if implementing abort-if-running (properly -- the current implementation is pretty gross) requires a significant amount of work, then I think it should not be prioritized above things like writing an SMF developer guide, and can be done later. (Though I suppose changing the behavior later could be very bad.) > or a package delivers a > critical but not obviously related service. I regard the latter as badly built > packages. > > (Any examples of obscure relationships?) I don't know of any obscure relationships off the top of my head, but I haven't seen sufficiently strong guards against building bad packages which give me confidence that this won't happen in the future. David
