> Personally, I'd like to see these things put through the Sun/Solaris > engineering thought process. Too often in the OSS world things get done > without much consideration to how they fit into the larger scheme of things. > I'd hate to think we just pulling this stuff in without giving it the same > consideration we give to things that originate in Solaris.
I think it's a good idea to always apply good engineering judgement here and definitely seeing how a particular component integrates with OpenSolaris is important. However, if we needlessly change expected interfaces with an eye towards "improving" them, we risk being incompatible with the way the rest of the world interacts with that component. The end result is likely many potential users not being able to make the adjustment/transition to using that component on an OpenSolaris-based platform. I'm not arguing for a blanket waiver here but just to apply good common sense. If a new service was being proposed that delivered a start-up script under /etc/rcS.d, I would say requiring a smf(5) service manifest would be a good start. However, if that service included a well-known configuration file with its own rich syntax, I certainly would not recommend to the project team that they embed the configuration details as service properties. Or "hide" the configuration file in an unexpected place on the file system if /etc was where everyone else stored the file. dsc
