Mailinglist Archive: zypp-devel (230 mails)

[Klaus Kaempf <kkaempf@xxxxxxx>]

* Jano Kupec <jkupec@xxxxxxx> [Feb 26. 2008 23:45]:

> 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@xxxxxxxxxxxx
For additional commands, e-mail: zypp-devel+help@xxxxxxxxxxxx