Roland, Dave and Alan: 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. 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) ? > > ---- > > Bye, > Roland >