* Martin Vidner
On Fri, Nov 09, 2007 at 03:27:18PM +0100, Klaus Kaempf wrote:
* Martin Vidner
[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...
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@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org