Josh Hurst wrote: > On 9/21/06, James Carlson <james.d.carlson at sun.com> wrote: >> Josh Hurst writes: >> > > It's the lack of an important usage case -- one that can't be handled >> > > in any reasonable way with /usr/bin/ksh93 -- that makes me ask why >> > > this needs to be done right now. >> > We don't need /usr/bin/ksh93 either - there is no important usage case. >> >> Nonsense. Many people (myself included) want to have /usr/bin/ksh93. > Well, you want it but you are not willing to pay the price? > >> > We don't need libshell.so.1 either - there is no important usage case. >> > We don't need libcmd.so.1 either - there is no important usage case. >> > We don't need libdll.so.1 either - there is no important usage case. >> > We don't need libast.so.1 either - there is no important usage case. >> >> These are all needed for ksh93. > No. You can link them statically. There would be no need for any of > these libraries. There is no need for ksh93 in ON either. You could > put it into sfw. Or you could download it from blastwave. They have a > ksh93 package. But you want ksh93 in ON. You want the libraries as > separate shared libraries. Why do you refuse to go one step further > and accept that the libraries are put into /lib?
The consolidation that it integrates into is not really relevant to this review. The only time a consolidation is relevant in ARC review is where there are Contracted Consolidation Private interfaces and this case has none of those. The review is about putting ksh93 into Solaris and OpenSolaris, that means it can integrate either into SFW or ON consolidations. We have a split of libraries between /lib and /usr/lib, thats a fact. Any project wanting to add to /lib rather than /usr/lib needs to justify that. While it might be "nice" to have /sbin/ksh93 as part of this project some of us don't see it as necessary for this project to be a success. ARC review doesn't always have a binary out come, part of the point of doing technical reviews in software development is to refine the design to one where there is consensus. While it is great if the original design does end up being the final one it doesn't mean it is bad if it doesn't. Sometimes is is better to reduce the scope ever so slightly if it means you get to do more faster now or do more easier later. >> > This argumentation can be extended over the whole project. As long as >> > /usr/bin/ksh exists in Solaris ksh93 could always be declared >> > redundant. >> >> Sorry, but that clearly misses the point. > I disagree. It is an example that there is no fair judgment possible > in this case. So we aren't allowed to comment at all and express our opinions ? > Roland and April are laying the foundation for future work and in my > opinion it should be their decision where they want to place the > libraries. That is not how OpenSolaris works and it isn't how Solaris worked before we created OpenSolaris. The way it works (more or less) is that the project team (Roland and April being key members) makes a proposal. You have a review of that proposal, as part of having a review people pick up on things that they don't understand or may not agree with. Discussion happens (this is where we are just now). Ultimately consensus is reached. Part of that consensus may mean changes to the original proposal. Now personally I would really like to hear from the project team on this issue, are they willing to drop the /sbin/ksh93 for now and cover this later or do they thing it is a critical part of the success of the initial phase of this project. -- Darren J Moffat
