* Duncan Mac-Vicar P.
On Thursday 01 November 2007 03:33:23 pm Klaus Kaempf wrote:
Hi,
discussions about sat-solver implementation details over the last days showed that a lot of decisions should not (cannot ?) be hardwired.
Instead, a policy should be in place to make solver operation configurable.
Nice that this was kicked off. For some moment I was afraid we were walking in the same hardcoded direction as the current solver.
*g*
Revision 7734 of sat-solver now contains a generic policy interface (src/policy.h) and a ruby based policy implementation (src/policy-ruby.c). It currently supports a single policy for demonstration purposes.
I don't like the idea of linking the core library and all tools against ruby.
Neither do I.
I think the policy engine could be dlopened and the ruby part should be inside bindings/ruby which is the only part of the library that depends on ruby.
Right. However, I don't have any experience with dlopen. The policy engine should be specified in some .conf file.
I can't complain loud because I don't have a patch :-(
Hehe. Same with me ;-)
The goal is to make all policies optional and fast for the default case.
There is another issue to solve, testsuite. Tests and policies. How to solve that?
Lets put it on the DISCUSS list. Klaus -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org