On 06/ 4/10 02:11 AM, Richard Lowe wrote:
On Jun 4, 2010, at 4:39 AM, Jonathan Haslam wrote:

This doesn't look quite right.  The first pass of dependency resolution
is on the set of manifests provided, so any system/kernel dependencies
should be resolved with the .140 version.
This is #15647, assigned to me, but likely to be fixed by Brock when he
rewhacks Variant* use in pkgdep (or I can integrate it sooner, I think,
if necessary).
You'll probably have to excuse me as I'm a fairly naive IPS user but
would #15647 stop me image updating? As it is, I am completely unable
to upgrade a b140 system to my own project gate bits and, obviously, this
stops my work dead in its tracks. The reason I ask is that the cited bug
is a P4 and my symptoms are a whole lot more than that.
Feel free to bump the priority/severity as you see fit.  I should note that
when I set them, I didn't realize this was a possibility.

Would #15647 give the following symptoms? :

r...@va64-x4500b-gmp03:~# pkg install -v SUNWcs
Creating Plan |Planning for install failed:


pkg: No version of SUNWcs can be installed:
pkg://on-nightly/[email protected],5.11-0.140:20100603T104035Z: Suitable required 
dependency pkg:/system/[email protected],5.11-0.142 cannot be found

I believe it could, yes, because your packages constrain themselves
to build 140 only, but also depend on build 142.

If so, is there something I can do to workaround this? I may be missing
something simple so please feel free to point out anything at all you think
may be useful. As it stands though, I can do nothing.

I think the reason it's so problematic for you is that your build machine
is running a version later than that which you are building, so the dependency
cannot be satisfied, you say "I only want bits from build 140" and the bug
then causes you to depend on bits from build 142.  In any other situation,
you'd be fine (if your workspace was a newer or equal build to that on the
build machine).

One workaround would be to artificial increase the build# in your workspace
(set ONNV_BUILDNUM in your environment to 142 or higher), this is distasteful,
but I think would function as a workaround.

Another would be to build IPS with my proposed fix patched in, and use it:
   http://cr.opensolaris.org/~richlowe/pkg_15647-2/
I've tested it, and it's been through one round of code review.  That's
probably equally distasteful.

A -D flag was added to 'pkgdepend resolve' fairly recently that prevents
it from using the build machine's packages in its attempts.  If the flag
is available to you, and you don't mind losing dependencies on packages
other than those in ON, you could use that.

Brock, rather than doing as we discussed and you doing this with your
VariantSets wad, can I get an ok from you on the webrev linked above
(it's what you reviewed already, with your comments dealt with), and
I'll put it back when the pkg gate opens.
Yep, that's fine with me. All my pkgdepend stuff is queued behind my manifest signing stuff at the moment.
Brock
-- Rich

_______________________________________________
on-ips-dev mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/on-ips-dev

Reply via email to