David Bustos wrote: > Quoth Mike Shapiro on Mon, Jun 02, 2008 at 03:28:34PM -0700: >> On Mon, Jun 02, 2008 at 02:50:11PM -0700, David Bustos wrote: >>> 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? >> 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. > > I still think this boils down to user sophistication. This factoring is > fine for > > 1. users who know which services the package delivers and appreciate > not having to do an explicit svcadm disable > > 2. users who know to use (b) before doing (a) > > But it's not good for all other users. Of course there are no type 2 > users, since (b) doesn't exist. Which means, to me, that this comes > down to a judgement of whether a significant proportion of our users > are not type 1, and how the risk to one (losing data or other > consequences due to an untimely svcadm disable) weighs against the > benefit to the other (not having to run svcadm disable). Personally, > I think we should estimate a significant proportion of users as > non-type 1, since I myself don't want to remember such details about > every subsystem.
First, you can determine the services in a package today. You can look at the files that package delivers, and examine any manifests. It isn't pretty or clean (and this needs to improve since a new packaging system is under development), but I'd say that the number of users who *wish* to invoke pkgrm on a package, and are non-type 1 are small, willing to accept the risk, or will blindly do the delete anyways, as Peter suggests. We all may not remember such details about every subsystem, but we also don't go around typing pkgrm on random packages willy-nilly. We tend to have a desired end state in mind when we are removing a package. You're already risking losing data if you don't understand what the package you're removing delivers. (I could ask whether unsophisticated users who didn't explore the list of files to be deleted by the pkgrm should be prompted for every single one before the pkgrm is allowed to go through, but that's likely unhelpful.) > That said, sometimes the "user" is actually code written by a developer, > which we can assume to be type 1, and which we currently do not > accommodate. I think that's a bug in r.manifest. ? What's the bug in r.manifest here, given the constraints of the current packaging system? When I originally brought up this topic, it was due to the manual pkgrm case. If I was concerned only about automated removals by other software, I would have likely proposed another solution. liane
