Mailinglist Archive: zypp-devel (230 mails)

[Michael Andres <ma@xxxxxxx>]

On Thu, Feb 07, Michael Matz wrote:

> IMHO the concept of "candidate" is non-sensical when seen from only the 
> solver side of things, as it is exactly a solvable.
>
> In my mental model only "selectable" and "solvable" make sense.  A 
> selectable is a set of solvables (which happen to have the same name, but 
> let's think of them as being an arbitrary set).  Now there are two request 
> types to give to the solver:
>
> 1) "please install this selectable": i.e. install one of the set members, 
>    I don't care which (policies and solvability will determine which one).
>    The current form for this request is "install a solvable with this 
>    name" (as SAT solver job).
>
> 2) "please install this particular solvable": i.e. a specific solvable of 
>    which only exactly one exists in the SAT pool.  For the application 
>    perspective it is perhaps interesting to note (but irrelevant) that 
>    this solvable is also an element of some selectable.  But the solver 
>    request (as SAT solver job) is indeed "install solvable id so-and-so".

Right.

> A "candidate" doesn't enter the picture, or if it enters at all then it is 
> precisely the "particular" solvable of case (2) above.

Yes, but...

> 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).

The UI doesn't hande the case where '!=1' solvables are selected verry 
well. UI want's to display 1 version, 1 label, 1 description....

So if there is no unique solvable (pre)selected by the solver, the UI 
chooses one. Candidate is the item whichs data are displayed. Sometimes 
it is as well the one that gets installed. Sometimes it is not.



-- 

cu,
    Michael Andres

+------------------------------------------------------------------+
Key fingerprint = 2DFA 5D73 18B1 E7EF A862  27AC 3FB8 9E3A 27C6 B0E4
+------------------------------------------------------------------+
Michael Andres             YaST Development            ma@xxxxxxxxxx
SUSE LINUX Products GmbH, GF:  Markus Rex,  HRB 16746 (AG Nuernberg)
Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0
+------------------------------------------------------------------+

-- 
To unsubscribe, e-mail: zypp-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: zypp-devel+help@xxxxxxxxxxxx