J Duff writes: > I????m modifying OpenSolaris for use on a field system. Initially I need to > modify only the kernel. I plan to pick a stable version of OpenSolaris, apply > my kernel changes, build, and then perform a Cap-Eye Install. This will > become the image for my field machine. Since I haven????t BFU-ed, I can > continue to install packages on the field machine if necessary. ????All is > good.
Well ... maybe. It depends on whether you cross a flag day with your changed bits. > At some point in the future, I may need to modify OpenSolaris user space > utilities and libs. I believe this will require a BFU in order to > ????install???? my user space changes. Once I BFU, I will no longer be able > to install packages. This means that my field system will be frozen at this > point in time, and I will not be able to add packages to the field machines. > Is this correct? No. Packaging still works fine after BFU. What doesn't work fine is _upgrade_. BFU really isn't that different from Cap-Eye Install. The reason BFU nukes the upgrade-related information is that you end up with binaries on your system that don't match what's in the packages, so there's no good way to predict what will happen when installing the "newer" things from the upgrade medium. It's possible (likely, in fact) that the upgrade will cause your BFU bits to be removed, causing either a regression or a complete failure. The same is true with Cap-Eye Install. If you upgrade, you can regress the kernel parts you've installed, and end up breaking the system. > Is there some way to modify OpenSolaris user space utilities and libs without > destroying the ability of the machine to install additional packages? All that BFU and Cap-Eye Install do is to copy files to the machine. BFU uses cpio, and Cap-Eye Install uses tar. They're otherwise pretty straightforward. You can obviously do the same thing with just "cp". If you're careful. ;-} Neither causes the system to be "destroyed" for the addition of more packages. Both cause the system packaging to be in such a state that _upgrading_ the system becomes problematic. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
