Ah, I see. Thanks for the explanation. I wonder whether the zone issue
is similar...
Jordan
On 05/07/10 11:43, Shawn Walker wrote:
On 05/ 6/10 05:16 PM, Jordan Vaughan wrote:
Hello IPS experts,
I recently tried to image-update an internal SPARC machine from
OpenSolaris build 133 to build 138 using the internal development and
extras repos, but IPS installed build 134a instead. (I didn't do
anything special, just "pkg refresh; pkg install SUNWipkg; pkg
image-update --be-name=snv_138") I noticed that image-updating the 134a
boot environment created a build 138 BE. I'm not sure how pkg(5)
determines the most recent build, but the logic (or the internal 134a
release) is clearly broken: My system should have gone straight from 133
to 138.
image-update doesn't take you to the latest *available* version, it
takes you to the latest available version *that can be installed* given
your currently installed set of packages.
My guess is that what you ran into is that the solver in b133 couldn't
handle an upgrade that involved both renames and obsoletes so upgraded
to b134 instead which it could do based on your installed packages. Once
you got to b134, the extra package baggage was gone, and its solver was
able to update you to b138.
However, keep in mind that there will be times whenever the set of
packages you have installed will prevent you from upgrading to the
newest available build, and that is not broken or wrong.
In those cases, you may either be upgraded to a newer build, but not the
*newest* one, or you may see a message such as "no updates available". A
legitimate example of this would be if you had the qt package provided
by the kde-solaris community installed, which depends on mysql-4.
mysql-4 is obsolete in newer builds, so you can't upgrade the system to
some of the newer builds unless you uninstall that qt package first.
Cheers,
-Shawn
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
