J Duff writes:
> 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.
True.
> However, because I have not modified any of the user space binaries, I can
> add, upgrade, and remove packages freely and without consequences.
That's a little strong. Packages that deliver kernel bits would be a
problem.
> Do packages ever modify kernel binaries?
Sure. That's how the kernel gets on the system in the first place.
> If so, then my last statement isn????t entirely true, and I may indeed have
> problems upgrading and deleting packages in this scenario.
It depends on _which_ packages you want to modify.
> 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.
Actually, an upgrade could wipe out _both_ kernel and user space
modifications.
Upgrade isn't a user-only proposition.
> This will likely break my bits if my bits overlap with the package bits.
Right.
> The upgrade has no logic to detect more recent binaries and leave them in
> place assuming that they are backward compatible. Is this true?
It does detect them, but since you did ask to have the system
"upgraded," and since it doesn't know which one is "more upgraded"
than the other, it assumes your most recent request is the valid one
("please upgrade from this medium") and it moves the _older_ files
(i.e., the ones you placed there with BFU or Cap-Eye Install) aside.
They become "~10" files.
This all happens because the versioning information is in the
packages, not in the files themselves.
> You indicate that I can continue to add (not upgrade or delete) new packages
> without issues after a BFU or Cap-Eye Install.
You can add, delete, or overwrite packages after doing BFU or Cap-Eye
Install. The only "gotcha" is that packaging knows _NOTHING_ about
those two mechanisms -- they just overwrite the files. Thus, if you
modify packages that deliver the same bits as your BFU or Cap-Eye
Install, you'll end up removing some of your BFU'd/Install'd bits.
"Upgrade" doesn't apply to individual packages. It applies to the
system as a whole.
> 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?
Yes it does, and there's no way for the packaging system to detect any
such problem here.
BFU and Cap-Eye Install just overwrite the files. It's like opening
your editor and hacking away at /usr/lib/libc.so.1. The packaging
system doesn't know whether you intended to do that, if it was a
mistake, or what the story might be. It just knows that the file is
"different."
> 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.
The package install itself should work fine (almost) no matter what.
As long as the new binaries rely on things you haven't changed, and
the package(s) being installed are logically complete (i.e., you're
not installing half of the packages required for a particular
feature), the install will give you a working new package.
Only _you_ can determine whether that's the case.
--
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
