Roland Mainz wrote:
> The current solution for libcmd based on Sun's prefernce for
> backwards-compatibilty and MANY MANY other issues were addressed this
> way, too. Just renaming the Solaris version of libcmd.so and annouce a
> "flag day" isn't even 5% of the work which would need to be done (and I
> expect around three/four months/engineer to get that propperly done).
If the Solaris libcmd were to be renamed, I could have X & CDE modified
to use the new one in less than an hour. JDS would probably take about as
long if we asked the JDS guys. You could avoid flag day pain by adding
a symlink or the function filters for a couple builds to allow the other
consolidations to transition and then drop it once everyone has.
(Unless special arrangements are made, X, CDE, and JDS normally build their
packages for Solaris Nevada build "n" on systems installed with Solaris
Nevada build n-2. We have made special arrangements when needed, such
as when coordinating the Trusted Extensions integration across the
consolidations.)
--
-Alan Coopersmith- alan.coopersmith at sun.com
Sun Microsystems, Inc. - X Window System Engineering
