James Carlson wrote: [snip] > 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?
There is no justification right now. And based on the current discussion there will never be the need to move the libraries from /usr/lib to /lib because we won't start or porpose any projects if libshell ends in /usr/lib from the beginning. Just one example: A while ago two of our students were working on adding SCTP support (while I was doing experiments with adding SCTP support to ksh93) to SMF which required linkage against libsctp. At this point the students were faced with an ARC case to get libsctp moved to /lib (at this point the ksh93-integration ARC case wasn't running and noone else here had any experience with it) and simply backed-off and requested a different project because the inability to predict a possible outcome was not suited for a students project. And the same issue applies to any work on the events framework for SMF, too. If someone would start such a project which requires to move the libraries sooner or later the people will read this discussion (and ARC's rejection of keeping the libraries in /lib) and I think the immediate reaction will simply be that they request another assignment - just anything else which doesn't deal with moving libshell around again. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
