Klaus Kaempf wrote:
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 ?
Let me add another example from the CLI (zypper) world. We have 'zypper list-updates' command which uses it's own (!!big no no!!) algorithm to determine the selectable candidate for an update and presents this version to the user. Then again, the 'zypper update' command uses the very same algorithm to mark the resolvables for actual update. This is for sure not a good solution when we want YaST packager, YOU and zypper (and any future libzypp app - like a CIM provider) to be consistent. How this would be done if we drop the 'candidate-before-solving' concept? I guess like this: zypper list-updates will not show versions, it will just list the names of resolvables for which there are updates available. If the user is too curious, we need to make a solver run and see what did the solver choose to present it to the user (or should we always make a solver run to see if there are any updates for the installed resolvables?). A convenient solver/libzypp API would be then handy here e.g. solver.getCandidate(Selectable) which would return null pointer or throw an exception if called before solving. So i guess, CLI could live without the candidate-before-solving as well as GUIs or TUIs.
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.
I agree that the policies are solver policies, but for this particular task an API can be provided which would choose a 'candidate' from a 'selectable' (or a set of solvables of the same kind and name as is the situation in current sat solver). That is IF we agree that we want a 'candidate-before-solving'. Otherwise the API should act as described above. Cheers, jano -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org