On 09/20/2011 01:59 PM, Klaus Kaempf wrote:
Actually, I'd consider this a bug.
I imagine libzypp as a collection of modules using a common base for datastructures and API design. The modules are repo mgmt, solver, package download, and transaction commit. Libzypp should not try to reinvent the wheel or hide underlying implementations only where it provides real value.
ZYpp does not do that. The pool is just a thin wrapper on top of the Sat structures offering C++ style iterations (and all the features that come with that) plus memory management. zypp:Sat manages only the lifecycle of the pointers and offers an object oriented API on top of it. If ZYpp does not allow unattended access is for a very simple reason. If you have Pool *pool; and Id id; as this is not object oriented, Id is context-less, and valid only for pool. When you have a Solvable object, while the data type is just an Id itself, the functions that provide name(), and other operations, act on a specific pool, in this case a global one, managed by ZYpp. The same accounts for IdString which while being a simple Id, allows to handle them as a String, and Arch and other classes as just IdStrings. I am quite surprised that you find this a bug, when you had to do exactly the same once and invent xsolvable. ZYpp just took a different path and prefered to manage one pool instead of adding one Pool pointer to each solvable. If the sat-solver would offer a string pool shared across multiple pools, it would be cool to get rid of global objects, and IdString could have only a global string pool. The API we have been discussing tries to hide the fact that there are global objects. Even if they are, you use your own handler. It is like how garbage separation was implemented in Germany. You first train people to separate it, even if you don't have the infrastructure ready to process it yet. Duncan -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org