* Michael Andres
On Tuesday 20 September 2011 14:20:21 Klaus Kaempf wrote:
* Duncan Mac-Vicar P.
[Sep 05. 2011 11:19]: The question is how to provide bindings for the objects shared between libzypp and libsatsolver, like 'Solvable', 'Solver', 'Problem', 'Solution', 'Transaction', 'Pool', 'Repo', etc. But unfortunately libzypp is not an applayer on top of satsolver. You remember the "evolution" of zypp - we ripped out the old solver and plugged in a new one. At the same time the API towards the zypper, YaST and PK remained as unchanged as possible.
Most of the time this API prevents us from being more 'satsolverish'. The satsolver objects are implementation details, sometimes more, sometimes less exposed.
I couldn't agree more. And that's why satsolver-bindings do not just grab some satsolver include files and let SWIG generate bindings from this. Instead, the satsolver-bindings design starts from the problem domain (package dependency solving) with sample code in the target language. It all revolves around "how should 'dependency solving' look like when I use Perl/Python/Ruby". Satsolver internals are exposed where it adds value (i.e. to enable id comparison vs. string comparison) or where it doesn't alienate the target language.
But there are several contrains libzypp enforces and translations it applies and which prevent us from offering unattended access to the satsolver objects.
That's fine and needs to be documented. However, adding another layer of abstraction increases the effort for the developer and the consumer of bindings.
Zypp and Sat sometimes speak a different language.
They shouldn't. Zypp should extend the language of the problem domain instead of translating it to a different language.
A quite obvious difference is the solvable 'name' and the solvable 'architecture':
- In satsolver by convention all patch names start with 'patch:' and all pattern names with 'pattern:', and every name that has no known prefix is a package. Among all packages, source packages are identified by having architecture 'src' or 'nosrc'.
- Within zypp all solvable names are unprefixed. A solvable attribute named 'kind' exists, telling whether it's a package, patch, pattern... Sourcepackages are of kind 'srcpackage' and their architecture is 'noarch'. A 'src' nor 'nosrc' architecture does not exist within zypp.
And its the task of the bindings to hide such implementation details.
Also the tight linkage between a 'product' and it's -release package is something which is asserted by zypp and must not be broken by direct satsolver access.
Its a question of effort and resources if libzypp should completely prevent this or add a simple "you might shoot yourself in the foot" warning. ;-)
I'm not sure whether common bindings are a low hanging fruit.
The alternative seems to be a refactored libzypp, a useful C API, and new bindings on top. Looks like a lot of work to me. Klaus --- SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org