Jan,
thanks for picking up this thread.
* Jan Kupec
Let's agree on what a candidate is (installation candidate, right?).
Before doing this, let me question the need for a candidate per se.
Is it one of the resolvables (or pool items) of a Selectable considered to be the most suitable to be selected for installation based on current setup of policies?
Thats the current definition (from my understanding).
Is it just a hint for the solver about what should be installed in case the user doesn't specifically choose another version?
This is not needed. The name is a sufficient hint for the solver to choose the 'best' package. However, the user is free to choose a specific version (evtl. from a specific repository) thereby limiting the solvers ability to compute an optimal (in terms of size, overall number of changes, etc.) solution.
Is the 'candidate' tied to a particular Selectable or is it rather a candidate of multiple Selectables (the whole pool perhaps)?
Klaus suggested the term 'candidate' is misleading. Why? If the candidate is for some reason not installable (which will be determined by solving), is there a problem with still calling it a candidate?
Candidate != to-be-installed, right?
Right. And thats the problem I want to address. Showing a 'candidate' at the UI, one which might not be installed, his highly misleading. "zypper in foo" is the normal use at the command line level, you don't "zypper in foo-1.2.3.i586". Why should the graphical UI, supposed to be more userfriendly and less technical, display an arbitrary technical detail ?
If the answers are positive, the Selectable::candidate() should return the candidate based on current policies
The policies are solver policies, so you need a solver run to execute them.
and should be used by the UIs to mark it for installation
If the user marks the candidate (having a specific version from a specific repository), this is very misleading.
(if user clicked to install the selectable (no specific version)) Thats (no specific version) is how it should be. But one doesn't need a candidate in this case.
by the solver to mark it for installation to satisfy some dependencies. And that's just about it. If not, please correct me.
Anything else?
I hope i'm not messing things up :O) *g* Not at all. Clearing this up is overdue.
Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org