Josh Hurst writes: > 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?
Because having it in root is not part of the price. > > These are all needed for ksh93. > No. You can link them statically. As long as there's no other use for them, I'd be fine with having them static. I'm not opposed to that at all. > 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. No, I don't. I want it in Solaris. Having it in SFW would be *fine*. It solves the problem of integrating it, provided that we don't care about the built-in duplication (and divergence) problem. > 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? Because they're not actually needed there. > > > 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. Really? > 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. No, that's not how it works. If you want to make a change, you must justify your change. It's not just "so-and-so has deemed it appropriate." It needs a technical argument, which is what I'm asking for here. Of what use is putting ksh93 in /sbin? If it's to go there, then why don't the rest of the shells move there as well? I can't see much of a purpose to this. The meager handful of scripts that run before /usr is mounted aren't going to be rewritten in ksh93 (nobody's proposed doing that). The /etc/passwd entry for root doesn't need it (you can still use /usr/bin/ksh93 just fine). The argument seems to rest on disaster recovery (without a separate boot medium) on a system with a split root-/usr and with a damaged /usr that can't even be mounted read-only. If that's the entirety of the use case, then I still maintain that it's not a necessary part of the project, because each of those issues has a better solution. -- James Carlson, KISS Network <james.d.carlson at sun.com> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
