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 - As Michael mentioned, libzypp does not allow raw manipulation via the satsolver API on one side and then using libzypp on the other side - 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. - 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 I think that having functional code in the bindings is re-inventing the wheel. Any code not using scripting languages would need to rewrite that code. 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). 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. - ZYpp is a great way to implement this API. Using the plain satsolver was not bad at all, but is a very raw API - 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. On the other hand, there are some things to improve: - mls is using the repo load callback mechanism to simplify the whole workflow of downloading/caching a repo. This approach rocks. - What we need from libzypp in order to implement the API is not all of it. I tried extracting the sat:: layer but it couples with other parts. What you mention above fails to solve the C access and the task-oriented API at the same time. Also we seem to have a kind of agreement how this API should look like and it does not resemble what we have there in any way. I see various approaches: Approach I - Be pragmatic: Step 1: - Implement this API using libzypp and offer nice bindings for it. Step 2: - Remove what we don't need of libzypp and fix some long standing issues. - Remove classes that we can get from boost. - Stop the template meta programming and the typedef party that makes people get scared of it (Except where it is useful, like the mixings and containers) - Stop the pimpl Approach II - A completely new path - Implement the API using the plain libsolv API - Reimplement the rest from scratch. (like solv.c) Is clear that a new path would cause regressions. I would only go this route if it is a long-term effort. Sadly maintaining PackageKit and zypper is something we have to do today. A funny experiment would be to implement the API in both ways, one to solve our current problem, and another one to put what we learned. -- Duncan Mac-Vicar P. - http://www.suse.com/ 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