On 09/20/2011 07:09 PM, Michael Andres wrote:
- 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.
Yup. And that is why I have never seen sat-solver as an "API". I understand that the bindings hide its drawbacks, but I am talking as a C API here (which we need). Prefixes, Id math with non-opaque structs, etc. Nothing for application developers. Great for building APIs on top of it. There is stuff that can be improved though. And the current draft of the ZYpp C api does indeed only offer one opaque ptr called "zypp_solvable". For the C++ part, I actually do like the object hierarchy, which is really useful for building user interfaces, which usually means holding base classes in ListViews. -- 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