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? > > 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. Do you not have arguments to put the libraries into /lib and you do not have any arguments against it. 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. -- Josh
