Darren.Reed at sun.com writes: > Is there a bug already opened that captures the problems > associated with removing an SMF service via a patch or > upgrade? Or an bug/RFE to use a mechanism other than > the file /var/svc/upgrade/profile?
There's a bug against making r.manifest automatically handle pkgrm -R, which I *think* will cover the removal part of your concern. (6438829, though it's unfortunately got most of the useful detail in the comments. If someone wants to move the comments to the description, that'd be great.) As long as your removal scenario includes the r.manifest class action script being executed for your manifest, 6438829 should cover it. For re-adding, I suspect you're falling afoul of the annoying fact that manifest-import runs too late for you. I'm not sure if there's an explicit bug against that, but we're working to staff a project ASAP to do early manifest-import (i.e. essentially before any services have started). Unfortunately, for your case and most of the others, a fix for pkgrm -R won't be enough unless if we move manifest handling to much earlier in boot. That's why we're working ASAP to staff early manifest-import. > I hope to have some time to review the Enhanced SMF Profiles > design soon to see how this situation will improve. I'm not convinced that Profiles helps directly here. It might provide us some of the mechanism necessary to solve the problem, but doesn't intrinsically solve it. The case you're looking at is actually pretty simple and we should be able to make it Just Work without the service author needing to do anything except for specify their manifest as the "manifest" class in the package. liane
