Quoth Nicolas Williams on Thu, Jan 15, 2009 at 03:00:13PM -0600: > I understand now that "delmanifest" is intended to delete services -- > not manifests -- that were delivered by auto-imported services.
It doesn't delete manifest files, but it does delete the repository's knowledge of such a file, and therefore the services they delivered. In any case, I'll revise the text to clarify this. > A few comments: > > a) A force option to "delete" seems more appropriate (and certainly less > confusing, if only to me). That would facilitate the wrong mental model. When a user removes a manifest from /var/svc/manifest and wants to propagate that change to the repository, requiring "delete -f" for the services it delivered requires more work, magnifies the opportunity for error, and requires special logic in svccfg to handle dependents properly. It's a lot easier for everyone involved for the user to just tell SMF which file he deleted, and have the facility take care of the rest. > b) Will one still be able delete, with the "delete" sub-command, > manually created instances of services delivered by manifests? > > I would expect the answer to be "yes." Yes. Such instances will be treated as administrative customizations. > c) A service deleted with delmanifest will be autoimported again unless > the manifest [or pkg delivering is] removed. This is just an > observation. I don't know if this is a problem or not, though I > suspect it's not. That's right. The reason delmanifest exists is for users to propagate the deletion a file from /var/svc/manifest. If he uses delmanifest but doesn't delete the file, then he's pretty much asking for the manifest to be re-imported. David
