Klaus Kaempf wrote:
Pool.each_to_install do s
implies that Pool is a handle to the current transaction and each_to_install is a filter on this transaction.
Sure, but also implies you have to copy every possible status (or transaction state) to the API. Still, I think those convenience methods are worth it, even if they have little to do with "model" or "architecture", at the end it will look only slightly different at the syntax level (because the fact that sat solver do has a each to install is just coincidence and implementation detail, and how you implement the loop is arguing about microseconds of difference ). Actually, for the UI model, iterating and then comparing the status is much more valuable, because they iterate, and then set icons or colors depending on the status. If they would need to iterate per status, then they would need to do acrobatics using maps to match each items. That is why I insist this is no model or architecture, just convenience methods (and actually for the UI they are still useful to show summaries I guess) Another argument is that only a few pieces iterate looking the different status to do something, because most applications go over commit() which does it for you. What I would like to see improved is the code to inject transactions. think zypper has lot of useful code. The part where it _is_ boring to iterate because unlike commit, each application has to reinvent the wheel, is to set a transaction. Unlike the example above when setting a transaction, you can have nonexistent objects, or strings, so iterating over the pool to find a package and mark it for installation, is duplicated code, instead of using the code zypper has to install by name, capability, etc. So We should really move that code to some libzypp namespace and allow for zypp::install("foo") (and document really well what does this do exactly). Duncan -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org