* Jano Kupec
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.
Thanks to sat-solver, this should be a problem of the past. The list of updates computed by sat-solver already have all dependencies solved. (So the list of updates is 'guaranteed' to be installable.)
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.
The problem is choosing between 'all' updates and 'installable' updates. E.g. a kernel update might not be installable if a driver dependency breaks. sat-solver only reports 'installable' updates.
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.
Yes. And this API would be part of the application layer. 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