* Duncan Mac-Vicar P.
On 09/02/2011 10:53 AM, Klaus Kaempf wrote:
* Michael Andres
[Sep 02. 2011 10:49]: We can also work on the zypp solvers API side. AFAIK the solver is basically able to resolve requests like 'install one out of a set of packages'. There's just no zypp side api for this.
The complete solver api, including policies, is available in the satsolver bindings. Exposing these in the libzypp bindings should be fairly simple and also prevent from re-inventing the wheel.
While it would be cool, it has the following problems:
- satsolver is not different to libzypp. Is not a task oriented API but a model of the problem domain. Not to mention it does 30% of the problem
You have looked at the satsolver-bindings and the example code ? Can you provide an example to make it even more task-oriented ?
- As Michael mentioned, libzypp does not allow raw manipulation via the satsolver API on one side and then using libzypp on the other side See my previous mail. I think this is wrong.
- Almost every client tool where we want to reduce code duplication is not using any scripting language. We want to offer bindings for _future_ tools.
Shouldn't future tools be implemented in a scripting language ? The porcellain/plumbing model, e.g. git is using, seems very desirable to me.
- While moving away from libzypp sounds like simplifying the problem. I think is just an instance of a known mistake: http://www.joelonsoftware.com/articles/fog0000000069.html
Is anyone proposing to move away from libzypp ?
I think that having functional code in the bindings is re-inventing the wheel.
Can you give an example for this concern ?
Any code not using scripting languages would need to rewrite that code.
Which code not using scriting language are you envisioning ?
I experimented during the weeked with the small API (zpm_query_what_provides and zpm_query_search) using 2 different approaches:
- Using libzypp, and hiding its classes into this light swig friendly API - Using satsolver only. Reusing code by mls in his example solv.c (parsing and download of repos, download of packages, etc).
This compares apples with oranges.
The feeling I got doing those experiments:
- A C task-oriented API would allow zypper, YaST and PackageKit to deduplicate code and if the API is good, nice bindings.
Ah, so you're targeting a C api here. Then using SWIG is certainly the wrong approach. However, I currently cannot imagine many consumers of a C API.
- ZYpp is a great way to implement this API. Using the plain satsolver was not bad at all, but is a very raw API
Thats why satsolver-bindings provide a (C language) 'applayer', making the satsolver API much more approachable.
- Implementing all the other requirements: memory management, selectables, powerful filters and search, key management, repository management, media abstraction, etc in plain C together with the satsolver (basically the experiment I did using mls solv.c code) is a step backwards.
Of course ! And noone is questioning that. The question is how to provide bindings for the objects shared between libzypp and libsatsolver, like 'Solvable', 'Solver', 'Problem', 'Solution', 'Transaction', 'Pool', 'Repo', etc. My proposal / offer is to use the API already existing in satsolver-bindings for the shared objects. OTOH, given sufficient time and resources a completely new approach is possible. 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