Mailinglist Archive: zypp-devel (78 mails)

[Klaus Kaempf <kkaempf@xxxxxxx>]

* Duncan Mac-Vicar Prett <dmacvicar@xxxxxxx> [Nov 05. 2007 16:33]:
> 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@xxxxxxxxxxxx
For additional commands, e-mail: zypp-devel+help@xxxxxxxxxxxx