On 02/ 2/12 08:39 AM, Alan Steinberg wrote:
On 02/ 2/12 07:54 AM, Alan Steinberg wrote:
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?
I answered my own question. In addition to declaring the variant in
the package, it needs to then be used for each applicable file.
-- Alan
From an older email from David Comay, there was a problem with pkgmerge
and the advice was given to just put the standalone variant in the
package manifest. But the importer.py tool that generates the "entire"
manifest isn't labeling ldoms as sparc-only. Is this a bug in
importer.py? I don't think it is expected that RE modifies entire by hand.
-- Alan
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
_______________________________________________
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
