Mailinglist Archive: zypp-devel (78 mails)

[Michael Matz <matz@xxxxxxx>]

Hi,

On Fri, 2 Nov 2007, Klaus Kaempf wrote:

> > 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.

For better or worse, I have :-)  Though I'm not sure if that's the way to 
go.  In my mental model it would work like this:

* policies are outside of solver (I think on that we all agree), solver 
  just calls back into them from time to time
* CoolApp wants to use satsolver, and also implement its own set of 
  policies, so it will have all the code for those very policies,
* CoolApp just needs a way of communicating that set of policies to the 
  solver

Hence a function "set_policy (struct policies *)" would be completely 
enough.  Where struct policies could look similar to this:

struct policies
{
  int (*archchanges) (Solvable *a, Solvable *b);
  int (*allowdowngrade) (Solvable *a);
  /* And so on.  */
};

I.e. I would want to make the solver somehow be responsible for loading 
policies automagically.  I would want the using applications to actually 
set them.

Let's not write yet another plugin system.  I've seen too many, most of 
them bad; it's usually a sign that the developers don't have any other 
ideas anymore.


Ciao,
Michael.
-- 
To unsubscribe, e-mail: zypp-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: zypp-devel+help@xxxxxxxxxxxx