Hi, On Thu, 7 Feb 2008, Jan Kupec wrote:
Let's agree on what a candidate is (installation candidate, right?).
IMHO the concept of "candidate" is non-sensical when seen from only the solver side of things, as it is exactly a solvable. In my mental model only "selectable" and "solvable" make sense. A selectable is a set of solvables (which happen to have the same name, but let's think of them as being an arbitrary set). Now there are two request types to give to the solver: 1) "please install this selectable": i.e. install one of the set members, I don't care which (policies and solvability will determine which one). The current form for this request is "install a solvable with this name" (as SAT solver job). 2) "please install this particular solvable": i.e. a specific solvable of which only exactly one exists in the SAT pool. For the application perspective it is perhaps interesting to note (but irrelevant) that this solvable is also an element of some selectable. But the solver request (as SAT solver job) is indeed "install solvable id so-and-so". A "candidate" doesn't enter the picture, or if it enters at all then it is precisely the "particular" solvable of case (2) above. This also means that a candidate is not just a hint for the solver. If you request it to install a certain solvable X, and that can't be done for whatever reason, then it will tell you exactly that. It won't chose some other solvable as replacement (except perhaps to give you potential solutions to the problem). So also from that side there's no difference between candidate and solvable. And certainly a candidate never are multiple solvables. That's what selectables are for. If you want to retain the concept of candidate, then certain invariants are sensible: * a candidate also is exactly one pool item (solvable) * a candidate is a member of exactly one selectable * a selectable contains zero or one candidates * if a selectable contains a candidate the job for the solver is "install that solvable X", no other jobs result from this selectable * if a selectable contains no candidate the request for the solver is "install any solvable providing this name" (or any other common thing based on which we defined the selectable). Then there's the conceptual difference between before and after solving. I suggest that the concept of "candidate" only exists before solving, for the application layer (simply to mark one selectable member as "the one to install"). After solving the candidate doesn't exist anymore. Only the set of to-be-installed-or-deleted pool items exists. All of them happen to be elements of selectables, and some of them might be equal to what formerly were candidates (indeed, if a selectable contained a candidate then either the to-be-installed-or-deleted pool item is equal to it, or a solving problem occured). It doesn't even make sense to have only one to-be-installed-or-deleted pool item per selectable. Updates for instance are implemented as "remove this, install that" where this and that are possibly from the same selectable. Hence, after solving, there can't be a selectable method which gives you the one "interesting" solvable. So again, candidates don't make sense after solving anymore. Ciao, Michael. -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org