Michael Matz wrote:
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.
Why not call the one to-be-installed the 'candidate after solving' (forget the rare case where there are more such resolvables for now) and provide a method for that? It would make sense e.g. to present to the user which version will be installed AFTER solving and BEFORE proceeding with the actual installation. There are more examples i guess. Check also my other recent post in this thread. Cheers, jano -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org