Josh Hurst writes: > On 9/21/06, James Carlson <james.d.carlson at sun.com> wrote: > > Martin Schaffstall writes: > > > On 9/21/06, Casper.Dik at sun.com <Casper.Dik at sun.com> wrote: > > > > None of the arguments have swayed us so far and James explained that > > > > arguments prefixed with "in the future we may" are best dealt with > > > > in future ARC cases when things may be moved around if the need arises. > > > > > > Is there any argument which has swayed you to accept /usr/bin/ksh93? > > > > Yes. Just asking for it is enough. I think it's a great idea. > Why are you then tearing this project into pieces? If you continue > this way then there will be nothing left to integrate.
We're doing no such thing. We're discussing the content of the case in order to find out why certain decisions were made. That's the purpose of having a review. > > > Or libshell? Or libast? I seems that there is no compelling reason to > > > accept ksh93 at all > > > > None of this justifies putting ksh into root. > I thought the ARC process is there to watch over long term changes and > make sure that projects have the proper long sightedness. Indeed. > If that's > the case the shortsightedness to remove /sbin/ksh93 and remove > libshell.so.1 from /lib is a paradox which needs to be explained. There's no paradox. It's short-sighted to allow a project to integrate just part of a useful solution, or integrate something that isn't in fact useful but has cost. The plan to replace /sbin/sh may or may not ever happen. It sounds like a nice goal, but it depends on future work that is _not_ a part of this project proposal. What is the purpose of /sbin/ksh93? It seems to me like a distraction. It doesn't help those who still log in as root, as you can already change root's shell to something under /usr/bin, and the system will do the right thing. It doesn't help much with system start-up scripts, as most of those run after /usr is mounted. It doesn't seem to make solving any other problems any easier, but it does bloat out the size of root. Moreover, a future project that actually has a need for /sbin/ksh93 (or a replaced /sbin/sh) could do so without causing trouble for the system. Adding in /sbin/ksh93 doesn't cause trouble for any applications. It's binary-compatible. Moving the libraries from /usr/lib is trivial and involves no incompatibilities -- just a couple of symlinks. So what can the justification be? -- 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
