Jan Kupec wrote:
Duncan Mac-Vicar P. wrote:
As long as the user did not explicitly choose a specific candidate, the app layer automatically chooses one from the available resolvables. That automatic choice takes matching architectures and most recent version number into account. This is not trivial. Right now the UIs do this choices in some random code somewhere in the UI, or using the selectable candidate function, which is now incomplete. This kind of decision is the same as the solver local policy. So we have to connect them trough the API somehow. Imagine this something like: bestCandidate( list_of_candidates, task )
Of course this has to be in Selectable, but it has to be connected to the local policy, and it depends on the task you want to execute.
Otherwise the UIs will continue breaking things like vendor (the UIs iterate over a package list and select the higher version instead of the best candidate according to the system policies ).
I bet we all agree on this, this stuff must be handled in libzypp.
Before we continue to discuss this, let's settle on the term 'selectable' so that we know what we talk about. See my mail "Selectables and 'candidate'".
i meant 'candidate', sorry, but the selectable needs to be ironed out, too :O) -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org