Quoth Liane Praza on Tue, Jun 03, 2008 at 11:33:39AM -0700: > 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),
Right, except the user has to know that SMF services are delivered by manifests. To me, that's part of "sophisticated". In particular, I would consider someone not familiar with SMF "unsophisticated" in this regard, and that would include people coming from operating systems without SMF. > 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, I disagree with the quantitative judgement, but I have no evidence. Risk tolerance is interesting. I'm not sure what to make of it. > or will blindly do the delete anyways, as Peter suggests. 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. 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. Hmm, is it ok to disable service X now? No, wait, I should tell users to log off first." I suppose you could argue that for software which isn't Solaris-specific, users should be familiar with the general problem that services need to be shut down before their files are removed. That does leave Solaris-specific software which unexpectedly deliver SMF services, which is probably pretty small. > 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. Right, but if your mental model doesn't include the fact that the files are in use, then is it better to risk the problems in yanking the files, or to fail the operation so that the user can correct? It depends on the number of users and the risk. Though some might say that traditional Unix philosophy dictates that we not care about the user's mental model, and let him learn the hard way. > 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.) I think they should be prompted about files which are in use, such as kernel drivers. Kernel drivers, however, are common in other operating systems, so it's easy to put the responsibility on the user, whereas SMF services are not common. > >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? That there's no way to tell it that the package is being removed noninteractively, so it shouldn't abort if the service is still running. This is 6574218, "non-interactive handling of manifest removal needs to be supported". David
