I need to detect the presence of SMF on an alternate root (that is, a root other than the one that's currently being used, as, for instance, in an install scenario).
The usual SMF presence detection code looks for the door, but as the door is dynamically created in a tmpfs that won't work in the alternate root scenario. What I'm doing now is looking to see if /etc/svc exists. Any opinion on how valid that is? --- A bit of background may be in order. I'm working on some packages that need to work on multiple versions of Solaris, and so need to dynamically adjust whether they use SMF or /etc/init.d scripts. (Actually, it's worse than that because I also have to handle Linux. Don't ask.) Of course, I want the SMF handling to be done by i.manifest as much as possible. My current plan is to mark the manifest as class "manifest", and then have checkinstall dynamically add that to the CLASSES pkginfo parameter if SMF is present. The net result will be that it will be installed (using i.manifest) if SMF is present, and will not be installed if it isn't. (Yes, I know that i.manifest is available only with a patch; that patch is a prerequisite for this package on S10.) One unaesthetic side effect of this strategy is that I'm unconditionally delivering /var, /var/svc, /var/svc/manifest, /var/svc/manifest/application, and /var/svc/manifest/application/SUNWuce. That's harmless on non-SMF systems, though there is the risk that it might confuse similar SMF-detection code that looks for /var/svc instead of my choice of /etc/svc. Comments?
