Quoth Jordan Brown (Sun) on Tue, Sep 25, 2007 at 09:19:35AM -0700: > 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?
It seems that none of our paths are Stable. As such, I think the best path would either be a public SMF command, or /var/svc, since we direct third-parties to deliver into /var/svc/manifest. > 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. Hmm, if that's possible, then I think testing the path of a public SMF command would be better. David
