Jano Kupec wrote:
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. For the sake of completeness, this is actually what zypper {lu|up} --best-effort tries to do, but it does it again on it's own instead of just calling the solver and there's no convenient API to get the selected resolvables in order to present them to the user if requested. -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org