Dale, You make some assumptions about a group of people you call 'devs', and you are correctly describing a certain class of people, but your description doesn't cover all users of compilers.
There are two different kinds of users in this discussion. Sometimes they are the same person wearing two hats at different times of the day, sometimes they are different people. Scenario 1: I download an open source package that I want to try out. I type "configure;make install". What happens? Ideally, you get some binaries and things work. In this scenario, I don't care if my compilers are the same as they were last week, as long as they work. I might not be a full-time software developer, I'm just a person with a Solaris box who wants to add some software to it that's not already in our repository. Scenario 2: I am a full time software developer working on a long-term one-person project or part of a larger group doing development on a software package. I will have clear opinions about whether I want my compiler updated or not. In some cases my software won't be very compiler-dependent, and I'll be happy taking whatever the latest default bundled compiler is. If I get burned by a compiler compatibility issue, or if I know a-priori that I need to use a specific version, or if there are CBE rules for my project, then I will have a specific version of the compiler that I want to use. In this case, I will want to control the version of the compiler separately from my control of the version of the Solaris OS that I am using. Perhaps we should have had more discussion in the one pager about the business justification for doing this, but our intent was clearly towards Scenario #1. Perhaps we should be trying to solve a different problem, but I really think that discussion is not an ARC discussion. If people think we're trying to solve the wrong problem, then let's collect a list of interested parties and take that discussion offline, because at that point we're no longer discussion ARC case that was submitted. Dale Ghent wrote: > 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 > > >
