Can anyone point me to any docs on, or provide any insight into, the algorithm emerge uses to resolve DEPEND requests? I can't make heads or tails of the results I'm getting from "emerge system".
I'm maintaining a set of ebuilds locally for a number of internal packages. I am trying to control them as a group using a single ebuild "wrapper" that depends on them; version 1.0 of the wrapper would have: DEPEND=" ~local/xxx-1.1 ~local/yyy-1.4 ~local/zzz-2.0 " then version 2.0 of the wrapper would have different versions. Then I put the wrapper into my packages file and when I run "emerge system", I should get what I want. Internally these packages have their own DEPEND lines, and they may well be less restrictive; local/xxx-1.1 might say it depends on "local/zzz" (any version) for example. But, it doesn't work the way I'd expect. I assumed emerge would examine all the DEPEND requests and come up with a list of packages which met all the criteria (or give an error if there wasn't one). Instead what seems to happen is that emerge sees the DEPEND with no version in local/xxx-1.1 and pulls in the latest local/zzz. Then it proceeds along and sometime later it discovers that it really wanted an earlier version so it installs that instead. Not only that, but I tried to arrange my packages in the wrapper DEPEND so that the ones that didn't depend on anything were first, etc. so that, if emerge did them in order, I'd get the right versions in the end. I didn't expect to have to do this but I tried it anyway; no help. Emerge merges them in some seemingly random order anyway. I'm using Portage 2.0.49. Can someone give me some tips/help/pointers/debugging advice/anything? I'm pretty stuck here :-(. -- ------------------------------------------------------------------------------- Paul D. Smith <[EMAIL PROTECTED]> HASMAT: HA Software Mthds & Tools "Please remain calm...I may be mad, but I am a professional." --Mad Scientist ------------------------------------------------------------------------------- These are my opinions---Nortel Networks takes no responsibility for them. -- [EMAIL PROTECTED] mailing list
