* Michael Andres
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. 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. 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