Roland Mainz wrote: > Milan Jurik wrote: > > mary ding p????e v ne 21. 06. 2009 v 14:01 -0700: > > > Roland Mainz wrote: > > > > Alan Coopersmith wrote: > > > >> Roland Mainz wrote: [snip] > > can you reevaluate this change once again, please? It will simplify > > upgrade and testing and there is no real benefit for all in SUNWcsu. > > Erm.. as discussed via Jabber/IM: > 1. I slightly disagree since we're talking about hard-links here. From a > historical point-of-view the distribution between "SUNWcsu" and > "SUNWesu" makes sense (or better: "May" make sense... so far noone was > able yet to explain the reason for the creation of "SUNWesu" or which > kind of categorisation was done to decide which tool goes into "SUNWcsu" > and which go into "SUNWesu"... ;-( ) since the tools were all standalone > binaries with no further dependicies but _now_ (with this putback) the > code now physically lives in "SUNWcsu"/"SUNWcsl" and splitting hardlinks > off into "SUNWesu" does IMO not make sense. From the standpoint of OS > package upgrade logic the split into two packages would make it even > more tricky since both "SUNWcsu" and "SUNWesu" would require an update > in the same update transaction (note: I am talking about packaging logic > here, not common sense... ;-( ). > IMO the packages should be created on a basis where the _code_ > physically lives. Since the code now moved phyiscally we should do the > same for the package entries. > 2. The PSARC case materials for PSARC/2009/249 and PSARC/2009/063 > explicitly describe the move from "SUNWesu" to "SUNWcsu" and changing > that would require another ARC case to superset both of them and that > costs us another 1-2 weeks [snip]
I forgot one point: 3. The shell has a builtin&&hardcoded list of commands which are available as builtin commands. If we put such commands into different packages than the ksh93 ([1]) one we may risk running into a possible "hiccups" where the commands aren't installed in /usr/bin/ but the shell treats them as such ([3]). [1]=Actually it may be libshell.so.1 since /usr/bin/ksh93 (more or less ([2])) directly jumps into libshell.so.1 [2]=yes, yes, I know: /usr/bin/ksh93 is a hardlink to /usr/lib/isaexec which calls /usr/bin/$(ISA)/ksh93 (e.g. /usr/bin/sparcv9/ksh93 on SPARC etc.) where $(ISA) may be the first (matching) item from the list returned byx /usr/bin/isalist [3]=OkOk, this is a shameless "lie": ksh93 conforms to the POSIX standard which requires that the shell must |stat()| the matching location in /usr/bin/ before using a builtin command bound to the /usr/bin/-PATH element the first time (later "lookups" are cached by the current shell instance). In this case removing commands from /usr/bin/ will disable them in the shell, too... however there is then the problem that there are stale "references" to non-existing commands (and I don't like having such "loose ends" floating around). ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;)
