On Thursday 12 March 2009 10:08:36 Klaus Kaempf wrote:
* Michael Andres
[Mar 11. 2009 17:51]: The 'new' solver api you mentioned should not be announced too loud, because the goal is to unify resolvePool() and resolveQueue(). I'd like to move towards one interface that fits CLI and UI. This will allow to provide most of the operatinos within the Selecatble api.
I wonder if 'Selectable', originating from the needs of the Qt UI, is the right class to deal with in a generic API.
Well, it's not the verry same Selectable. But if you look at Jano's list, there are 2 major keys: byName and byCapability. An then some minor ones like arch, version, repo. The current UI-Selectable groups packages by name. You have easy access to all packages with the same name. You see the installed and available ones. You can file solver request, and you can inspect the results. Extend Selectable to give easy access to all packages providing a specific capability. And to manage the Capability based request. Selectable is (will have to be) a filter byName/Capability and some convenience to inspect the result, and manage the solver request. And it's the place to build request not (yet) directly covered by the solver, like 'install package foo with vendor baa'. The Selctable will translate this into a 'install one out of many' request. Or say you want to install a specific source package with or without solving its builddeps. Of course one can manually create and file a solver request to install 'capability libfoo', solve, and then search through the result queue to see which specific package is also a provider of libfoo.
Going forward, I'd like libzypp to offer four (distinct?) APIs:
- repository management This would cover add, edit, remove repositories including key handling, as well as 'refresh' and .solv creation.
- information management All 'search' type operations as well as solvable attribute handling.
- dependency solving This would cover all solver operations, esp. creating a transaction (install, update, remove of packages), 'distribution update', dependency solving and problem/solution handling.
- commit Starting with a successfully solved transaction, this would cover all package download, package cache, pre-req ordering and the actual RPM operations.
The named areas also hint on the granularity of locking in our attempt to remove the 'big' zypp lock.
yes. -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres YaST Development ma@novell.com 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@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org