Mailinglist Archive: zypp-devel (78 mails)

[Klaus Kaempf <kkaempf@xxxxxxx>]

* Martin Vidner <mvidner@xxxxxxx> [Nov 09. 2007 15:42]:
> On Fri, Nov 09, 2007 at 03:27:18PM +0100, Klaus Kaempf wrote:
> > * Martin Vidner <mvidner@xxxxxxx> [Nov 09. 2007 15:12]:
> > > On Fri, Nov 09, 2007 at 02:20:27PM +0100, Klaus Kaempf wrote:
> > > > as sat-solver/doc/README.policy
> > >
> > > http://svn.opensuse.org/viewcvs/zypp/trunk/sat-solver/doc/README.policy?view=markup
> > >
> > > anyway, beware of overengineering.
> >
> > You're invited to help in this regard ;-)
>
> OK...
> Here's how I see it in order of increasing complexity:
>
> A) No policies.
>
> Just hardcode it in the solver.
>
> B) No interface.
>
> Code it in the solver, but parametrize the decisions by
> /etc/zypp/zypp.conf:
> solver.prefer_arch_over_version = false
> solver.downgrade_automatic = false
> solver.downgrade_user = true (?)
> solver.uninstall
> solver.vendor_change

A and B are ruled out because

- we have to deliver 'role based' software management
  (e.g. allowing non-root user to install updates)

- security demands that non-root users must not downgrade packages

- however, root is allowed to install version downgrades

=> the 'allow downgrade' policy must be settable at runtime


> C) Interface.
>
> Like (B), but separate the decision code from the solver.

Right, policy is all about separation of the decision code from the solver.

> I see a single interface point now:
>
>       policy->get_boolean("prefer_arch_over_version")

Thats how the current sat solver implementation handles it, just that
the boolean values are passed via a struct.

> D) Scriptable Pluggable Chainable whatever

I believe we have to target D) since it puts us 'on par' with
other software management tools, e.g. yum.


Klaus
---
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)

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