On Jan 15, 2009, at 6:44 PM, Chris Quenelle wrote: > Please back up a step and help me understand why we need to deliver > parallel versions through Nevada, and not just through our existing > channels.
I honestly don't know why I, myself, are taking such a interest in this case, but if I had an idea it might be because I and perhaps a few others are taking the long view based on past experience. But as you urge, let's put aside implementation details for a moment and focus on the concept. Hopefully I can articulate my argument well enough, so here goes: You know, compilers (or suites of them) are a menagerie in their own special way, different from programs such as 'ls', 'sed', 'dc', and 'vax'. Devs tend to stick to a specific Major version (and the more pedantic, a particular Minor version) and upgrade only when arbitrary circumstances require it. When it does come time move to a successive compiler version, the new version has to co-exist with the prior one for at least some amount of time. GCC's way of handling this is with appropriately-named executables, command-line flags, and version- specific directories. Unbundled Sun Studio's way is to keep all of a Major version in its own tree under /opt. This case requests to bundle a subset of the unbundled Sun Studio suite directly inside ON. Excellent. For C/C++, we would have arguably the best compilers readily present in the default $PATH. No neophyte users having to learn that they need to add /opt/whatever/bin to their $PATH and thus short-circuiting any "But in Linux..." quips. But! ...but what is the real utility and maintainability of doing this given the described culture that exists around compilers? Choosing what version of Sun Studio goes into ON might be easy now, but what about in the future when we will have to *replace it* (not supplement it) with Sun Studio 16? How will updates/patches be reconciled between the bundled and unbundled variants? Take these questions and pile the key one on top - "How would users react to that?" Okay, so the response would be "Well, then install the unbundled full version of Sun Studio." All well and good, and without question the user would definitely be getting the bits he/she desires. But then what of the bundled Sun Studio that continues to sit around in /usr/ bin and /usr/compilers ? It becomes a vestigial appendage sitting on prime realestate. The user could of course remove it, but then where's the win in that? The intent of this case would then cease to offer any benefit to the user and we're back to square 1. So I think that some of us are urging a little architectural and usability foresight to be applied here. Nothing irks users (myself included) more than having to do a package and $PATH dance to make things "right." Seasoned vets such as ourselves might roll our eyes and say "figure it out and fix your path, ya scab" but we must remember who we're trying to attract to OpenSolaris and what platforms they're coming from. /dale
