>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.
Tearing to pieces? We only have qualms about where in the filesystem it will be delivered. Not that particular pieces need to be removed. >> 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. 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. Why? We explained why we don't like putting it in /sbin for the initial integration. Arguments like "shortsightedness" aren't really compelling. This is the bit of the system which gets run before /usr is mounted: online Sep_15 svc:/system/svc/restarter:default online Sep_15 svc:/network/pfil:default online Sep_15 svc:/network/loopback:default online Sep_15 svc:/network/physical:default online Sep_15 svc:/milestone/network:default online Sep_15 svc:/system/identity:node online Sep_15 svc:/system/metainit:default online Sep_15 svc:/system/filesystem/root:default online Sep_15 svc:/system/scheduler:default online Sep_15 svc:/system/boot-archive:default online Sep_15 svc:/system/filesystem/usr:default Casper
