Hi Florian!
On Tue, Jan 03, 2012 at 01:08:42PM +0100, Florian Festi wrote:
[...] Libsolv is an interesting implementation for a depsolver but does not offer the API we are looking for. It needs some kind of abstraction layer to hide all the moving parts. This is one of the things libzypp does. Yes, the "bare bone" C part of libsolv is probably not what you're looking for. The usage of Ids instead of pointers is a tad confusing, e.g. a package is described by (pool,id). A pointer to a package can become invalid when another package is added and so on. The interface itself isn't moving that rapidly, I just used the sat-solver -> libsolv rename to get rid of some old cruft and do some function name cleanup. Yes, we have noticed the sat-solver -> libsolv transition. Do you already have an idea when this step is going to be completed? It looks
But did you look at the perl/python/ruby bindings? They provide a saner high level interface (at the cost of slowing things down, obviously). (Klaus Kaempf also wrote some glue code called "applayer", which offers a similar interface in C for the old sat-solver library. He used it for his bindings, I currently have the layer in the swig code.) Yes, we had a look at the bindings (and examples). They are better than
It seems like you also want to provide repository management and download functions in your new API, that's currently not in scope of libsolv (and probably never will be). We are still trying to figure out how the different pieces need to be
On 01/03/2012 02:04 PM, Michael Schroeder wrote: like people work on both trees right now. the pure C API but still expose many implementation details. We'd rather not even expose the ids in the API but just the strings (or other tag data). As long as the API is located just below the cli the overhead should not matter much - even if the API is an order of magnitude more expensive than the direct lookup by id. put together. For now we'd try to hide libsolv as an implementation detail similar as libzypp does. On the long run I can imagine moving the libsolv code into librpm - replacing rpm's dependency check. But there is a lot of other stuff to do before even thinking about the details of such a step (e.g. adding support for 64 bit integers to libsolv).
Are you already in discussions with the yum folks about their needs? Maybe they have some suggestions about how the interface could look like. (You do want yum to use your new API, right?) Yes, we are in discussion with the yum folks. But a new depsolver will require a new data format (aka pool). Replacing both will not keep a lot of stones on one another within yum. So we will decide later whether and how to integrate the depsolver into yum. For now we are rather looking for getting things right than staying compatible.
Florian -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org To contact the owner, e-mail: zypp-devel+owner@opensuse.org