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: > > >>> Since libcmd and /usr/bin/alias are in SUNWcsu already it doesn't make > > >>> sense to try to split hardlinks over multiple packages (I don't even > > >>> know whether that's possible without opening a "can of worms" somehow). > > >> It's possible, as shown by the plethora of commands split across a wide > > >> range of packages that have hard links to isaexec. (32 packages on the > > >> SXCE 116 machine I just checked.) > > > > > > Mhhh... Ok... but I am not sure whether it makes sense to split it > > > between "SUNWcsu" and "SUNWesu" ([1]) since the code lives in > > > libcmd.so.1 which is already (even now, ksh93-integration update2 only > > > delivers bugfixes in this case) in the "SUNWcsl" package (= "SUNWcsu"'s > > > counterpart for shared libraries). From the technical viewpoint it's > > > possible... > > > > > > [1]=Just curious: Why was this split originally made, e.g. why are the > > > basic POSIX/SUS commands split over multiple packages (sounds like a > > > good way to cause trouble for script writers) ? > > > > For Nevada, it might not be an issue. However, I had seen problems in > > update releases. Basically SUNWcsu always get pkgrm during upgrade > > since it had VERSION=1000, so any packages that had hard link to isexec > > also needs to be pkgrm and pkgadd back again in s10 updates. > > > > In Nevada, since ON always redeliver with newer version and rev#, it is > > not an issue because all ON packages will be pkgadd. > > > > With OSOL, I do not believe it will be a problem. > > 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 IMO - based on [1] and [2] - we should stick with the original plan and move the tools from "SUNWesu" to "SUNWcsu". However I agree that it may be usefull to create (later, not this putback, please (we're almost done with testing and all other required stuff)) a set of new packages (e.g. "SUNWastlibs", "SUNWposixcmd" ?) to split this stuff off from "SUNWcsu"/"SUNWcsl" as earlier suggested in this thread. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;)
