Since each C-team delivers its own incorporation package without any
manipulation by RE, it is an LDOMS c-team issue, so I will reroute the bugs.
S11 SRU4 received the new version of ldoms before S11 Update 1. If it
followed the normal soak time order, would it have made a difference? In
other words, will the results be different for U1 Build 9 which will
have the new version of LDOMS in it?
Additional questions below:
On 02/ 2/12 06:35 AM, Shawn Walker wrote:
On 02/02/12 06:23, Enda o'Connor - Oracle Ireland - Software Engineer
wrote:
Hi
I am on SRU4 Build 4 and tried to go to s11 update 1 build 8
but ran into issue with entire in u1 depending on FCS ldoms
incorporation, whereas SRU4 entire has dependency on SRU4 build2 ldoms,
logged CR etc.
I then tried x86 as I wanted to test u1 stuff, but ran into same ldoms
pkg dependency issue on 86, so logged 7142088 to get variant.arch set to
sparc only for this dependency, at least I think that is right way, as
ldomsis clearly sparc only.
You got the update error because older versions of the
ldom-incorporation don't have a variant.arch=sparc, so its installed
on x86 systems, and the new version of the osnet-incorporation you're
attempting to update to doesn't allow the latest version of the
ldoms-incorporation available for x86.
Unfortunately, ldoms-incorporation is required by 'entire', so you
won't be able to remove it. So entire needs to have the
'ldoms-incorporation' require dependency marked with variant.arch as
well.
In Solaris 11 Express the ldoms incorporation was delivered to RE with
variant.arch=sparc on every line, while for Solaris 11 11/11 it was only
included in a standalone line "set name=variant.arch value=sparc". Is
the ldoms incorporation package incorrect in addition the the "entire"
package?
Since the "entire" package is built during the RE assembly process using
importer.py, did it leave out the sparc variant because the ldoms
incorporation manifest was incorrect?
-- Alan
But my query now is why does the x867 failure appear a lot better and
more verbose than the sparc failure ie
...
So whatever about the reject line for every ldosm incorporation, I do
see this
Reason: Excluded by proposed incorporation 'entire'
Newer version
pkg://solaris/consolidation/ldoms/[email protected],5.11-0.175.0.4.0.2.0:20120119T202509Z
is already installed
Reject:
pkg://solaris/consolidation/ldoms/[email protected],5.11-0.175.0.0.0.1.0:20111012T230609Z
Reason: Newer version
pkg://solaris/consolidation/ldoms/[email protected],5.11-0.175.0.4.0.2.0:20120119T202509Z
is already installed
Reject:
pkg://solaris/consolidation/ldoms/[email protected],5.11-0.175.0.4.0.2.0:20120119T202509Z
Reason: Excluded by proposed incorporation 'entire'
which is a lot better than the error I got on SPARC.
I guess that on saprc where the ldoms pkgs like ldomsmanager get pulled
in, this has some solver side effect of making the error less verbose
than x86?
The solver error code isn't platform-specific, so any differences
you're seeing are because the dependency graph (and set of installed
packages) is different.
-Shawn
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
