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.
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.
> 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?"
Sure. pkgrm seems like a presentation layer to me, though. (Without
arguments, at least.)
> Clearly if nothing else decide the answer for IPS,
> since we certainly won't go back and address this in legacy packaging.
Right.
David
