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. -- Rich _______________________________________________ on-ips-dev mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/on-ips-dev
