Hi! We at Red Hat are currently looking for a C based depsolver and C API for package management. In addition we are considering a deeper integration of the depsolver with rpm - both on API and code level. While depsolvers and rpm do different things they are much more similar than the current code bases would suggest. We actually did a prototype implementation in Python of such an integrate design a few years ago [1] (based on a yum-like depsolver). For package management we need a simple API on top of the whole stack that is easy to use. Target audience are tools dealing with packages but not changing the way we deal with packages - like CLI or GUI installers/updaters, system management tools, ... This API needs to hide a lot of complexity and should only offer access to the installed and available packages, allow running simple commands and doing simple adjustments to the configuration (e.g. enable/disable repositories). For plugins and more complicated tools we will probably need another - more complicated - API that is closer to the metal. It would probably allow creating rules for the depsolver and would be dependent of the actual depsolver implementation. This API could be separate and come with lower expectations on stability. So one obvious thing for us to do was looking at libzypp and sat-solver / libsolv. While we have not yet settled to specific solution we already have some ideas and opinions. As there is a chance that you might do something similar and there is the chance to come to a more unified code base in the package management stack we want you to know what we have in mind early. Our conclusions so far: 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. The libzypp API looks pretty complicated. The "next-gen API for package management?" thread on the zypp-devel (September 2011) did not exactly dispel our concerns about that. As we need a C API using C++ creates a lot of overhead. If libzypp would provide the perfect API just putting a C layer in front would be a good way to go. But doing a lot of simplification within this step (as zpm [2]) will likely require tools needing access to "more internal" parts of the API to either be in C++ or wait for a new C layer being written. This is not a situation we are looking forward to. As we are not as attached to the functionality implemented in libzypp as you might be (we are not using Patches or Patterns) implementing the package management API in pure C is an option we are considering. This layer should also hide libsolv's implementation details from plugins or tools that interfere more deeply with the depsolver than "simple GUI applications". For tools implementing new features it is probably easier to do the implementation within libsolv and then export the new functionality than exporting an API allowing to do so. This kinda breaks the idea of different levels of abstraction but allows keeping the important code paths highly optimized - which is what libsolv obviously aims for. We are also thinking about using libsolv - or at least parts of libsolv for implementing functionality of rpm itself. First tests show that small but notable improvements can be achieved by swapping out data structures - even without replacing the whole mode of operation. We are also considering different approaches of integrating libsolv with the rpm dependency checker but even the basic steps are still undetermined. One possible model would be dropping rpmlib's dependency checker in favor of the sat solver and write some interfacing code. As a result of these considerations we are interested if your discussion about the "next-gen API" has led to further results since September and if you are already in favor of one of the suggested solutions. As the requirements are not fundamentally different for the different distributions there might be a chance of increasing the shared code base and may be even integrating *the* dep solver into RPM if this should prove to be beneficial. Florian [1] http://pyrpm.sourceforge.net/ [2] https://github.com/openSUSE/zpm -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org To contact the owner, e-mail: zypp-devel+owner@opensuse.org