Thanks. This is very useful information. Just to be sure I understand? Let?s assume I do not cross a flag day with my bits, i.e., I am able to make my kernel changes on top of the source code which matches the version of OpenSolaris that I originally installed on my machine. Since I?m making kernel changes (no user space changes), I do not need to BFU, but I do need to Cap Eye Install. However, because I have not modified any of the user space binaries, I can add, upgrade, and remove packages freely and without consequences. Do packages ever modify kernel binaries? If so, then my last statement isn?t entirely true, and I may indeed have problems upgrading and deleting packages in this scenario.
Let?s say that eventually I make user space changes and then need to BFU (or manually cp) in order to put the modified user space binaries in place. Now, I may have problems if I upgrade a package because the upgrade may overwrite the modified user space binaries with the older versions contained in the package. This will likely break my bits if my bits overlap with the package bits. The upgrade has no logic to detect more recent binaries and leave them in place assuming that they are backward compatible. Is this true? You indicate that I can continue to add (not upgrade or delete) new packages without issues after a BFU or Cap-Eye Install. But what if a ?new? package relies on one of the binaries I modified? Doesn?t this package carry an older version of the binary and try to install it? Perhaps by ?new package? you mean a package that contains and relies on only new binaries, and does not require any binaries that are already installed on the system. If so, I can see how adding new packages will continue to work despite the BFU or Cap Eye Install. Thanks for your time and for providing detailed information and insights. It truly helps novice OpenSolaris developers like me. This message posted from opensolaris.org
