* Duncan Mac-Vicar Prett
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.
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.
Agreed. The point I was trying to make is that iterating over the whole pool and checking status of pool items doesn't seem to be a good approach to me.
If they would need to iterate per status, then they would need to do acrobatics using maps to match each items.
Iteration per status is just one of many possible access methods. It could also be iterate per repository, search result, whatever. And I didn't want to remove status access methods from solvables. So one should still be able to use s.isToBeInstalled. Sorry for being unclear on this.
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).
I couldn't agree more. sat-solver (and sat-solver bindings) already provide a nice (documented) api for this. Klaus -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org