* Michael Matz
I agree that an attribute store and the solvable data structures need to be integrated somewhat, exactly for the reason you state, sometimes a solver (or something sitting on top of it) needs to know assorted information about solvables for whatever it wants to achieve.
A common theme for such information is that it's used only relatively seldomly (e.g. only when there are several alternatives, which are completely equivalent from a dependency perspective, but for which other information could provide guidance which of the alternatives would be preferred). I.e. it's used only when the depsolver itself can't determine everything on it's own. To that end such additional information usually is only accessed on demand.
This would be information for deciding a policy. And policies should certainly handled outside the solver core, imho. [...]
My intent is to implement all this "rest" information as side-band info to the solver itself, so that it doesn't take much space when it isn't actually accessed.
I fully agree to this implementation proposal. The solver core dould use 'policy callbacks' to the policy engine. This engine can take the extra attributes (fetched via the application layer) into account when deciding the policy. This way, a good separation of duty can be achieved without bloating the core solver. 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