Mailinglist Archive: zypp-devel (78 mails)

[Michael Matz <matz@xxxxxxx>]

Hi,

On Mon, 5 Nov 2007, Klaus Kaempf wrote:

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

You can circumvent them anyway when you're determined enough.  E.g. using 
rpm directly.  There's no hope you can employ a system wide policy without 
cooperation from the applications in question, they actively need to make 
use of them (i.e. at least activate them, and if as part of they 
"solver-setup" perhaps done in some library).  Now _where_ those policies 
are actually implemented is another question.  I for instance would not 
assume that every zypp-using app implements their own.  I would expect 
some middle layer to provide them.

That middle layer can be as configurable as you like, and also as 
extensible as you like, even using dynamic loading if you absolutely 
insist :)  Or as scripts.  But the point is that there should be something 
else than libsatsolver linking against ruby.  Even that middle layer 
should not link directly against it, (which then unfortunately indeed 
requires dynamic loading :-/ ).

But I would first start defining what callbacks are really required.  Each 
and every of them will cost considerable runtime for the solver compared 
to what it normally can do when walking his rules.  Premature optimization 
is the root of much evil, but the same holds for premature over-design.  
So if something isn't reasonably necessary to configure, better make it 
not a call back.  Or if something trivially is a global option, don't make 
it a callback working on Solvables.  Such and similar things should also 
be considered.

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

That would be bad of course.  As I wrote above, in my mind it would have 
been a library, which applications then are required to use.


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