* Duncan Mac-Vicar Prett
On Monday 05 November 2007 16:23:28 Klaus Kaempf wrote:
Time for a '/etc/solver.conf' file or a /etc/solver/policy directory to place a .so file with the policy implementation ?
That is exactly what Michael is trying to prevent. A new plugin mechanism.
Basically the idea is just to offer callback interface, and the application using the solver would implement them. No need for config files or plugins.
I don't agree with applications providing the policy. I can already see zypper (being C++ code) providing a C++ policy engine, effectively circumventing system wide policies. I'd like policies to be flexible (hence the implementation using a scripting language) and usable across applications (system wide policies). Application specific policies should be possible, but the exception.
The ruby bindings could implement them, gluing them to a ruby file with functions. While ZYpp could glue them to its own config file AND/OR UI iteraction.
This sounds like implementing several policy engines, one for each application. And making them sufficiently flexible will result in every application having its own plugin mechanism.
What we need now, is the list of policies, to design that interface,
Right. So lets meet with Michael Schroeder and draft that list.
and again, any idea on how to keep the testsuite running when the policies are not longer constant.
From my POV, the testsuite is one application using policies defined for the testsuite. It also shouldn't be too hard to load different policy implementations within the 'deptestomatic' test binary.
Klaus -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org