On 06/21/10 10:08 PM, Thirumalai Srinivasan wrote:
Folks,
Are there any simple rules regarding the inter-relationship of the
following
that will ensure a successul ONU of the bits from the workspace on to
the test machine ?
(A) onnv build number of the build server,
(B) onnv build number of the workspace being built,
(C) onnv build number of the test machine.
A = 141, B = 140, C = 136 fails to update the test machine with the new
ON bits
But if C is 140, then it succeeds.
Generally speaking, this is supposed to work. But a few notes.
If you build on a system with non-ON packages @140, your test machine must
have access to those packages. (e.g. libm, libxml, python)
Usually, that requirement isn't a big deal -- bfu allowed this situation
for many years. If you're simply doing development work on a workspace
that hasn't been synced up, just make sure your test machine can access a
repository (usually ipkg.sfbay/dev internally) which has those non-ON
packages available.
If you really need to test a fully "136" system (including the non-ON
bits) you can either build on a 136 build machine, or set
SUPPRESSPKGDEP=true in your build environment to suppress all dependency
generation within ON. (Make sure you test without this variable set once
you sync your gate up to recent bits.)
One caveat, there was a bug in "pkgdepend" which some people are hitting
in the scenario where the build machine is running a higher version of ON
packages than their build workspace. This usually manifests as
dependencies on system/kernel at the build machine's version. It's fixed
in the @0.142 version of package/pkg.
liane
_______________________________________________
on-ips-dev mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/on-ips-dev
